SOLVED - Re: ld: howto link a whole library or object file content to a specific section

[CortexFan <giancarlo dot parodi at gmail dot com>]

Dear all,
finally I sorted this out also thanks(!) to this previous post:
http://gcc.gnu.org/ml/gcc-help/2010-12/msg00176.html

It is both because of a prefix wildcard missing, and the way my build tools
work. I changed the syntax to 

    .my_sysshared : 
    { 
        *syscalls_minimal.o 
        *\libgcc.a:*
        *\libc.a:*

    } > SysShared

and this now is doing what I would expect, namely place the libs and the
content of syscalls_minimal.o into .my_sysshared section

For the records, regarding the syscalls_minimal.o part, my linker command
line looked something like:

-T ./.../linker.ld -mcpu=cortex-m1 -mthumb -Wl,-Map="./result.map"
--gc-sections -o result.elf ... "./syscalls_minimal.o" ...

this is the linker command line generated by the IDE I use (Keil uVision4)
for building the Cortex target image via gcc, it is passed to the linker
during the build process.


My personal explanation for this:

It seems that if I specify the filename without the leading *, the linker
treats "syscalls_minimal.o" and "./syscalls_minimal.o" as two different
files, although they have the same content. I think this is because of the
fact that windows uses backslashes for directories, so the characters "./"
are seen as integral part of the file name.

This is the map file I was getting:

.my_sysshared   0x10085000     0x2b54
 syscalls_minimal.o()
 .text          0x10085000      0x108 syscalls_minimal.o
 .data          0x10085108        0x4 syscalls_minimal.o
 .bss           0x1008510c        0x8 syscalls_minimal.o
...
...
 .text          0x180004a4      0x108 ./syscalls_minimal.o
                0x180004a4                _close
                0x180004aa                _fstat
                0x180004b4                _isatty
                0x180004b8                _lseek
                0x180004bc                _read
                0x180004c0                _sbrk
                0x18000500                _open
                0x18000506                _link

...
...


The linker referenced the same object module twice during the link, once as
syscall_minimal.o and once as ./syscall_minimal.o, then placed one copy in
the desired section  (from "syscalls_minimal.o), and another copy in the
default .text section (from "./syscalls_minimal.o" which is passed on
command line). 

At the end it was resulting in duplicate symbols, giving a link error >-(

I believe it is explained by the end of section 3.6.4.1 of the manual:

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.

The linker opened up "syscalls_minimal.o" himself, because of the mentioned
rule.

Adding the wildcard makes the problem disappear, as then *syscalls_minimal.o
covers both cases, so the file gets used by the linker only once. Probably
on Linux I would have never saw the problem &-(

Hope this can help also others in similar issues :-)

Cheers,
Giancarlo



CortexFan wrote:
> 
> ..snip...
> 
> however this does not work, and it seems that the linker is including
> again the text, data, bss sections within syscalls_minimal.o in the
> rest of the default sections I have defined later on - so I get errors
> of multiple definition of symbols like _close _fstat etc. I thought
> the text data bss from syscalls_minimal.o would be used only once.
> Using EXCLUDE_FILE (*syscalls_minimal.o) within the other sections
> defined, to tell the linker to explicitly ignore the file at that
> time, does not solve the problem.
> 
> 
> 2. second option mentioned in section 3.6.4.1 of the ld manual
> suggests using the 'archive:file' method to indicate an archive (or a
> file located within an archive) to be taken as an input to be placed
> in a specific section.
> 
> Assuming the archive is called libc.a, I tried several ways like using
> (for example) the notation
> 
>   .my_lib:
>     {
>         libc.a:lib_a-memcmp.o
> 
>     } > RAM_lib
> 
> but this does not work either. 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/ld%3A-howto-link-a-whole-library-or-object-file-content-to-a-specific-section-tp30464246p30472436.html
Sent from the gcc - Help mailing list archive at Nabble.com.