This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Revisiting libcygwin.a/libc.a/libm.a


On Tue, 8 Feb 2000, Chris Faylor wrote:

> >Remember it way too well. I did do some tests since and it seemed to work
> >with v1.0 CD version. I will check again this evening.
> 
> Hmm.  I thought that I checked with the CD version and it still had
> problems.  Now, what did I do with that test case...

I tried a few trivial apps on my system, which is running a fairly recent
snapshot on top of v1.0, and it worked for both C and C++ apps. C++ apps
are important due to global constructor issues, and we need to run some
real testcases before we can say it's ok. 

Now here's the problem: the following will work:
  
  $ c++ -o foo foo.cc -lc -lm

but this will fail:

  $ c++ -o foo foo.cc /path/to/libc.a /path/to/libm.a

if libc.a and libm.a are symlinks to libcygwin.a, and this is quite
possibly due to the linker getting confused with the various head_*
in the import libraries being pulled in out of order.

To get an insight, add a -v and see the order of the libraries, which
both the C and C++ drivers reorder when it sees -lc -lm on the command
line, but do not reorder when these are handed as libc.a and libm.a.

Solution? Create libc.a and libcygwin.a as separate import libraries
from the same set of exports, and libm.a from perhaps just the math
exports. Dlltool will use the archive names to create the head_ and
iname_ symbols, and linker will do the right thing hopefully. I need
to test this out before I can say this would work for sure of course.

Regards,
Mumit



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]