This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: speclib vs. -lc trouble.
Dave Korn wrote:
> Christopher Faylor wrote:
>
>>> Still not working for me. Get this when I try to link with the libc.a
>>> generated by that method:
>>>
>>> /gnu/binutils/obj5/ld/.libs/ld-new:
>>> /usr/lib/libcygwin.a(cygwin_crt0.o): bad reloc address 0x74 in section
>>> `.text'
>> Do you have a test case that you could post? I don't get this with
>> either a new or old linker.
>
> At the moment the only way I can reproduce it is in the ld testsuite, in
> the bootstrap tests. If I can distill a testcase out of it I'll post it
> here.
Starting to look like a real BFD problem. We have the same symbol defined
in two separate (but identically-named) members of two archives, libc.a and
libcygwin.a. At the time the final link comes to get symbols and relocs out
of the cygwin_crt0.o member, what it seems to be doing is looking in the file
content of one archive, but at the file offset at which the corresponding
archive member exists in the /other/ archive file. I think it may have got
confused.
We're trying to do comdat without using comdat, more or less; I guess this
probably isn't valid, there should only be one definition present for a given
symbol and when it digs the first one it finds out of the link hash table it's
no surprise it doesn't expect it to come from a different BFD than the armap
symbol it just looked up. Argh. I'll see if it's feasible to make it work at
the binutils end of things, anyway.
cheers,
DaveK