Hi all,

I am working in BREW and configured GNU ARM toolchain for compiling.

I used GNU ARM to compile my sources (.c files) which compiled fine, but when calling "arm-elf-ld" for linking the .o files, it complains about mulitple definitions of the included routines.

utils.o(.text+0x2a8): In function `ISOCKET_GetSockName':
: multiple definition of `ISOCKET_GetSockName'
paint.o(.text+0x2c10): first defined here
utils.o(.text+0x2fc): In function `ISOCKET_SetOpt':
: multiple definition of `ISOCKET_SetOpt'
paint.o(.text+0x2c64): first defined here
utils.o(.text+0x34c): In function `ISOCKET_GetOpt':
: multiple definition of `ISOCKET_GetOpt'
.....
make: *** [sudoku.elf] Error 1

All the above methods are caused by __inline methods defined in one of the BREW SDK file - AEENet.h.

I went thru many forums and came to a rough conclusion that GCC linking has problems in linking __inline methods. Most of the time they suggest to change "__inline" to "extern __inline" or "static __inline".

If I change like said above, the linking works perfectly. But I feel changing an SDK file is not recommended and also the same source compiles and links fine with ARM Dev Suite without changing.

Is this a gcc linker bug?
Is there any option in GNU compiling or linking to avoid this error.
[one option is add --allow-mulitple-definition flag, but that bloats up the code - so rejected]

Any help is very much appreciated.

Thanks in Advance,
R.Pradeep

The problem is not in gcc itself, but in a different definitions of __inline (as it's simply #defined). It maybe possible to fix the issue by undefining __inline at the beginning of certain files, but it depends how it is defined in different files. For example, how do the prototype of the functions causing errors look like in all files they're used?

Hi Mara.

Thanks for the reply.

I changed the AEENet.h (SDK header)file with "static __inline" (or) "extern __inline" (or) "#define". And then compiled the .dll for emulator. The app launches fine but when a network request is made, the emulator crashes.
So changes in the SDK header does not seems to be the right option in this case.

The same sources work fine with Visual Studio and also in ARM Dev. Suite compilers without any changes.
So I am little confused with using GCC linking options
Any idea why this happens in GCC alone?

Thanks,
R.Pradeep

With wrong __incline definition it should simply produce compile errors, not crash (excluding a case when there are two different functions with only return argument different and using __inline, which is unlikely). My guess is that the crash is unrelated. BTW which one crashes, emulator or program inside emulator?

Yes the compiler does produce error as I mentioned in the first post.
The crash occurs only when I change "__inline" to "static __inline" (or) "extern __inline" (or) "#define" in the SDK header containing the __inline methods.
This was suggested in certain forums to solve the linking errors posted in the first post.

Do you mean "two different functions with the same name" ?.
If so, then this is not the case, as the __inline methods are in the SDK header file. Which does compile and link without any errors in visual studio.

to be a linking problem with GCC, as the same sources works fine when used with visual studio and ARM dev. suite compilers.

The emulator crashes, when the application makes a network call.

I'm wondering how is __inline defined. Have you tried searching the SDK and your GCC environment (I think it's simply 'inline' for gcc). I'd try with __inline beeing simply 'inline', with no more modifiers. Another try - redefine __inline as empty, eg.
#define __inline

I meant your source having two functions, one is __inline somefun and another, for example static inline somefun. The result is diferent depending on the definiton of __inline.

I think it's unreated to the __inline thing. Not initialized pointer etc (compilers use different default values, so such bug may not be noticed when using one compiler while crashing happily when using another).

The SDK header contains methods like below:

// pseudo-methods
__inline int ISOCKET_Realize(ISocket *me)
{
return ISOCKET_IOCtl(me, ISOCKET_IOCTL_REALIZE, 0);
}
__inline int ISOCKET_Listen(ISocket *me, int nBacklog)
{
return ISOCKET_IOCtl(me, ISOCKET_IOCTL_LISTEN, (uint32)nBacklog);
}
......

I tried as you mentioned but the same error occurs and also gcc.info document mentions

(If you are writing a header file to be included in ISO C programs,
write `__inline__' instead of `inline'. *Note Alternate Keywords::.)
so for C, I think it should not be just "inline"

For this I had the same doubt as you said, and I checked out my sources for unintialised variables, pointers, etc., but none of them is directly related or used in the network request part of the code where the program seems to crash.

With the code you have provided, both static inline and inline cause no harm. It's only about code size in this case.

Which version? One of the possible redefines should make it compile.
It says about __inline__, not __inline. Which is often used, BTW.

Do you have any chance to see if it crashes near the functions that have problems with inline? You have an emulator, so finding the crash point should be easy.

Hi Mara,

I felt the same, changing it to static or to a #define does not affect the code. But it seems to crash when it is run in the emulator.

I use gcc 3.3.1 which come along with GNUDE, I also tried WinARM, which has a recent version gcc 4.1.1. Both throws out the same error while linking.


I did try getting the emulator output from the output window, but when the emulator crashes it takes out the output window with it. So from the visual clues [the application screen], the crash happens just after the network request is made.

My main confusion is why is GCC not able to compile and link "__inline" methods properly? Why is it needed to define it as static inline or #define to solve this problem for GCC alone?

My standard technique in such case is to insert printfs and sleep calls at the places I suspect. Sleeps must be long enough so I can notice what was the last message. It's not an effective method, but works for extreme cases

For gcc, "__inline" is equal to "my_own_modifier". it must be defined somewhere. In your case it seems to be defined twice and, what's not very good, differently.

Hi Mara,

Seems I have to go with VC and ARM ADS compilers for now, as I feel any changes to the SDK headers can cause problems in the device and also the app needs to be pass the True BREW Testing which has a cost associated with it.
Also BREW does not officially support GNU ARM.
Hope BREW support people will provide an updated header for this issue soon.

Thanks Mara for help and support extended.

Thanks,
R.Pradeep