#2591 Problem with "Multiple definition of _aligned_alloc_PARM_2"

[Ferenc Szili]

Hi,

I found a strange one while compiling my project for 8051. And I've made a minimal project which brings this up. We have two simple source file:

main.c

#include <stdlib.h>

int main()
{
  return 0;
}

func.c

#include <stdlib.h>

void func()
{}

Compiling:

sdcc -c main.c
sdcc -c func.c

Linking:

sdcc main.rel func.rel -o tst.hex
Multiple definition of _aligned_alloc_PARM_2

Even stranger is that the linker makes a tst.hex output, but returns an error to make. I did not look into what that output actually is.

sdcc used:

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.6.5 #9842 (MINGW64)

But I've seen this problem for a while now...

Thank you!

[john]

hi, i try to re-produce the problem that you have. i realized one thing. if you dont include <stdlib.h> in your hearder then, it wont complaining about anything. (i dont know why, and trying to look for it). hope this helps</stdlib.h>

[Philipp Klaus Krause]

Well, stdlib.h contains the declaration of aligned_alloc().

Philipp

[john]

do you still consider that as a bug? i think that has to do with the way that SDCC compiler works. or maybe i should say the way this compiler works is not peffect?

[Philipp Klaus Krause]

Looks like a bug to me. After all you get an error for compliant code. Since aligned_alloc() in stdlib.h is an inline function, there might be a bug in inlining.

Philipp

[john]

then do you knwo which file contain thoes functions? i just download the code, and i want to fix this bug, but i dont know which file should i focus on......

[Maarten Brock]

aligned_alloc is written as a so-called inline definition in stdlib.h and thus should not provide an external definition for the function. It appears this case is not tested in the regression test inline.c.

[Cristiano Rodrigues]

Hi there!

I'm having it also. But only if I compile with --std-sdcc11, if I compile with --std-sdcc99 I don't have any Multiple definition of _aligned_alloc_PARM_2

[Matt Barr]

A little late to the party here, I was just looking at this for a colleague who ran into the problem. I see the same thing that Cristiano mentions, the errors go away compiling with --std-sdcc99. Many thanks for this, and to John for the stdlib.h dependency.

Interestingly, in sdccman3.6.0.pdf we have:
--std-sdcc99 Generally follow the ISO C99 standard, but allow some SDCC behaviour that conflicts with the standard (default).

I get errors compiling without an --std-sdccNN option, so --std-sdcc99 does not appear to be the default in every respect.

[Philipp Klaus Krause]

Thanks for the catch. Apparently only the --help output, but not the manual got updated when the default changed from --std-sdcc99 to --std-sdcc11.
Fixed in revision [r9884].

Philipp

[Matt Barr]

Thanks Philipp. I am using SDCC with Silicon Labs C8051 on a Windows platform. I ran snapshot version 9880 and note a couple issues wrt. 3.6.0. One is that sdcc.exe does not automatically provide -DSDCC=365 similar to the definition in previous released versions. This breaks SiLabs' compiler_defs.h, easily worked around. I suspect this is intentional and will be added for the next official release, but mention it just in case it is an oversight.

The other issue, also easily worked around, is that the putchar prototype definition in stdio.h has changed from:
extern void putchar(char);
to:
extern int putchar(int);
I am surprised to see this in an 8-bit MCU environment and don't know whether to put it in the bug or feature column, so I thought it might also be worth mentioning.

Many thanks for the fixes and for your SDCC work in general.

Regards,
Matt

PS: Just saw ticket #2505, looks like the putchar() definition change is indeed a feature.

[Philipp Klaus Krause]

Both are intentional changes.

Philipp

[Maarten Brock]

Philipp, why are you so strong about removing this one important macro? This was the first macro to indicate the SDCC version to the code being compiled. There is a lot of code out there that depends on it. I suggest it to be reinserted. It already was only issued when sdcc extensions were enabled.

[Philipp Klaus Krause]

I'd like to see SDCC become fully complinat, and the differences between --std-sdccXX and --std-cXX disappear. The macro name makes it non-compliant. We now have (and have had for a while) better alternatives to this macro.

Philipp

[Maarten Brock]

I worked hard to get Silicon Labs to support SDCC in the past and managed to get them to deploy compiler independent header files by the use of this SDCC macro. In the meantime they changed their IDE to an Eclipse based one and it's once again Keil only. Can I assume that you will convince them to update their header files? Or can we expect this change to be the final push for them to abandon SDCC completely?

[Philipp Klaus Krause]

Are people using the old IDE and headers with current SDCC? How hard is it for users to change the headers themselves?

I'd assume that if Silicon Labs ever adds support for SDCC to Simplicity Studio, requiring a minor update to a header file to use the current macro(s) would be the least of their tasks.

Philipp

[Matt Barr]

Yes, and not hard. With the 5.18.00 version of the old IDE, at line 128 in C:\SiLabs\MCU\INC\compiler_defs.h I have:

#if defined SDCC

#if (SDCC >= 300)

I changed this to:

#if defined SDCC || defined __SDCC

#if (SDCC >= 300 || __SDCC_VERSION_MAJOR >= 3)

I have to confess to not understanding the beauty or advantage in omitting the SDCC definition. There are still a good number of SDCC-specific definitions added to the command line by sdcc.exe, and retaining SDCC=NNN maintains compatibility with the old IDE out of the box

I like a religious debate as much as the next guy, but I'm easy, I can live with either decision! I suspect the concern is that there are those who may conclude that a new version of SDCC no longer works with the old IDE, without taking the time to understand what is going on and how to correct it.

[Philipp Klaus Krause]

According to the manual, the only non-compliant define remaining is SDCC_PARMS_IN_BANK1 (and that one is only there when --parms-in-bank1 is used). All others should start with two underscores, as the standard requires.

Philipp

[Maarten Brock]

I would not mind for this SDCC_PARMS_IN_BANK1 to be replaced by a standard-compliant one. I very much doubt anyone uses it. I even expect the whole option can be removed without anyone noticing.

[Maarten Brock]

The old IDE can display multibyte variables in proper endianness, where Simplicity Studio cannot. And it can invoke SDCC which Studio can't.

Of course changing one header file is much easier than all the rest that is required for suppoting SDCC.

And any user could change the file as well. But this change is required by every user who downloads the files. And again after every update. And all this to please your feeling about standard compliance. And without warning of deprecation when building with the current version of SDCC.

[Philipp Klaus Krause]

Unfortuantely, it probably would be quite hard to implement the deprecation warning. But we have had the macros with compliant names for a long time now. For over five years, the manual only mentioned the macros with compliant names.
So at least those who looked at the manual had five years warning.

Since the only issue with the removal this macro seems to be for that old SiLabs IDE, how about reenabling the macro for mcs51 only?

Philipp

[Maarten Brock]

The same header files come with Simplicity Studio. But it seems only mcs51 is highly affected, so I can live with further restricting the use of this macro.

But please at least mention its deprecation in the release notes.

[Philipp Klaus Krause]

Fixed in revision [r9870].

Philipp

[Cristiano Rodrigues]

Confirmed.
Thank you very much :)

[Ferenc Szili]

Thank you!