Multiple definition of '__assert'

[Joel Sherrill <joel@OARcorp.com>]

Till Straumann wrote:
> Camilo Alejandro Arboleda wrote:
> 
>> Looking at BSP sources, there is only one call to assert (in ne2000 
>> driver), I'm going to try your recomendation and tell you the results.
>>
>> I don't know the linker internals, so there is a question that rise: 
>> Why does it works when I put console.c in my project?
> 
> 
> It depends on the order in which things are linked. If console.o has 
> already been added to the link
> when the linker looks for __assert it already has it and won't look for 
> it in libc.
> 
> However, if the libc version gets linked first and 'console.o' is linked 
> afterwards (note: in order to
> satisfy another symbol, not __assert) the linker also finds __assert in 
> 'console.o' and then
> does the sanity check (size comparison) which subsequently fails...

__assert shouldn't be in the BSP but knowing it uses printk() which is
supposed to work in the worst places makes me wonder if this shouldn't
be in a file of its own in a more universal place.  But then we would 
have to disable the one in newlib to be sure it wasn't showing up.

Kind of sounds like this just needs to disappear unless we want to
deal with tool issues.

For sure on 4.6, this should just disappear.  Maybe CVS head has a 
better (and more intrusive) solution.

> HTH
> Till
> 
>>
>>
>>
>> Till Straumann escribió:
>>
>>> Camilo Alejandro Arboleda wrote:
>>>
>>>> Hello,
>>>>
>>>> I worte to the list because of this problem, but there is no answer 
>>>> (yet).
>>>>
>>>> I'm using rtems 4.6.2, with gcc 3.2.3 and newlib 1.1.13. When I try 
>>>> to compile even a simple application agaist pc486 BSP I get an error 
>>>> message telling there is a previous definition of __assert.  My 
>>>> work-around was to copy console.c to my project directory, and 
>>>> compiling it as part of my project.
>>>>
>>>> Has anybody the same problem? 
>>>
>>>
>>>
>>>
>>>
>>> Yes. This is a bug. You should file a PR (after double-checking that 
>>> no one
>>> exists already). The PCx86 BSP provides its own version of __assert 
>>> although
>>> another implementation already comes with libc. The BSP's version 
>>> (among other
>>> things) uses 'printk' instead of 'printf' so that assert can be used 
>>> from ISR context.
>>>
>>> My suggested fix would be eliminating the BSP-specific implementation 
>>> from
>>> console.c and removing 'assert' statements from interrupt handlers 
>>> (pcx86 BSP).
>>>
>>>
>>> HTH
>>> -- Till
>>>
>>>> Any ideas or a cleaner work-around?
>>>>
>>>> The test program is
>>>>
>>>> | /* confdefs.h.  */
>>>> |
>>>> | #define PACKAGE_NAME ""
>>>> | #define PACKAGE_TARNAME ""
>>>> | #define PACKAGE_VERSION ""
>>>> | #define PACKAGE_STRING ""
>>>> | #define PACKAGE_BUGREPORT ""
>>>> | /* end confdefs.h.  */
>>>> |
>>>> | int
>>>> | main ()
>>>> | {
>>>> |
>>>> |   ;
>>>> |   return 0;
>>>> | }
>>>>
>>>>
>>>> and the error is:
>>>>
>>>>
>>>> /usr/rtems-4.6/i386-rtems/pc486/lib/librtemsbsp.a(console.o): In
>>>> function `__assert':
>>>> /cygdrive/c/rtems/build-rtems/i386-rtems-4.6.2/i386-rtems/c/pc486/lib/libbsp/i386/pc386/console/../../../../../../../../../../rtems-4.6.2/c/src/lib/libbsp/i386/pc386/console/console.c:151: 
>>>>
>>>> multiple definition of `__assert'
>>>> /cygdrive/c/cygwin/usr/rtems/i386-rtems/bin/../lib/gcc-lib/i386-rtems/3.2.3/../../../../i386-rtems/lib/libc.a(assert.o):/cygdrive/c/rtems/build-utils/gcc_3.2.3-i386/i386-rtems/newlib/libc/stdlib/../../../../../../source/gcc-3.2.3/newlib/libc/stdlib/assert.c:56: 
>>>>
>>>> first defined here
>>>> /cygdrive/c/cygwin/usr/rtems/i386-rtems/bin/../lib/gcc-lib/i386-rtems/3.2.3/../../../../i386-rtems/bin/ld: 
>>>>
>>>> Warning: size of symbol `__assert' changed from 41 to 133 in
>>>> /usr/rtems-4.6/i386-rtems/pc486/lib/librtemsbsp.a(console.o)
>>>>
>>>
>>>
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985