[U-Boot] [PATCH v3] Switch from archive libraries to partial linking

Albert ARIBAUD albert.aribaud at free.fr
Thu Nov 18 23:08:49 CET 2010


Le 18/11/2010 22:44, Wolfgang Denk a écrit :
> Dear Sebastien Carlier,
>
> In message<20101117133056.GB23875 at safe.home.local>  you wrote:
>>
>>> MPC8xx boards break with long lists of multiple definitions of
>>> symbols, like that:
>>>
>>> Configuring for FPS860L board...
>>> lib/libgeneric.o: In function `vsprintf':
>>> /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf'
>>> ...
>>>
>>> Have you seen that, too?
>>
>> Unfortunately I have not been able to reproduce these errors with the
>> toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
>> emdebian squeeze packages).  Can you please point me to the toolchain
>> you are using?
>
> Are you sure this doesn't happen with your tool chain?
>
> I found out why this happens, and I think the effect should be
> independent of the used tool chain:
>
> For example, in "board/tqc/tqm8xx/u-boot.lds" we arrange to have the
> environment located in one of the "small" NOR flash sectors:
>
> ....
>   53   .text      :
>   54   {
>   55     /* WARNING - the following is hand-optimized to fit within  */
>   56     /* the sector layout of our flash chips!    XXX FIXME XXX   */
>   57
>   58     arch/powerpc/cpu/mpc8xx/start.o             (.text)
>   59     arch/powerpc/cpu/mpc8xx/traps.o             (.text)
>   60     common/dlmalloc.o           (.text)
>   61     arch/powerpc/lib/ppcstring.o                (.text)
>   62     lib/vsprintf.o      (.text)
>   63     lib/crc32.o         (.text)
>   64     lib/zlib.o          (.text)
>   65     arch/powerpc/lib/cache.o            (.text)
>   66
>   67     . = DEFINED(env_offset) ? env_offset : .;
>   68     common/env_embedded.o       (.ppcenv)
>   69
>   70     *(.text)
>   71     *(.got1)
> ....
>
> That means, the linker script pulls in certain object files directly.
> Before, when linking with libraries, this was no problem, as the
> linker would pull only (so far) unresolved symbols from the libraries
> specified on the command line.  Now, we include these individual
> object files through the linker script, and then again when specifying
> the "library" objects on the command line - which necessarily results
> in "multiple definition" errors.

Are you sure of this? From 
<http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics>, 
specifying a file name in the linker file *and* on the command line 
should not lead to a double inclusion of the object file:

"When you use a file name which is not an `archive:file' specifier and 
does not contain any wild card characters, the linker will first see if 
you also specified the file name on the linker command line or in an 
INPUT command. If you did not, the linker will attempt to open the file 
as an input file, as though it appeared on the command line."

> Unfortunately I don't know how to solve this yet.  Does anybody know of
> a way how to manually arrange the objects (or symbols) in the linked
> image?
>
>
> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.


More information about the U-Boot mailing list