speclib vs. -lc trouble.

Dave Korn dave.korn.cygwin@googlemail.com
Sun Apr 12 16:15:00 GMT 2009

Christopher Faylor wrote:
> On Sat, Apr 11, 2009 at 11:19:24PM +0100, Dave Korn wrote:
>> 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.
> I could reproduce the problem and am in the process of testing a fix.
>> Starting to look like a real BFD problem.
> Yes, it was definitely some sort of binutils problem.  When I started
> playing around I was getting error messages relating to the wrong
> library.  I'd make a change to libc.a and get an error relating to
> libcygwin.a.  That was enough of a clue to realize that these special
> libraries need to look a lot less like import libraries.
> I'll check something in shortly.

  Here's a recipe to make a working libc.a from a broken (as currently
generated on head) libc.a:

ar x libcygwin.a d000000.o
ar rb d000001.o libc.a d000000.o
ranlib libc.a
objcopy libc.a libc2.a \
	--redefine-sym __head_cygwin1_dll=__libc__head_cygwin1_dll \
	--redefine-sym _cygwin1_dll_iname=__libc_cygwin1_dll_iname

  Going to play with it a bit more and try the other stub libs, but I think
it's probably all we need.  Because the symbol is now resolved by a head thunk
within the same library, the dubious if..then clause that switches the BFD's
filename on the fly never kicks in.


More information about the Cygwin-developers mailing list