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.
