This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Will libm.a always be a symlink? (or snapshot vs. release)
- To: Cygwin <cygwin at sources dot redhat dot com>
- Subject: Will libm.a always be a symlink? (or snapshot vs. release)
- From: Jason Tishler <Jason dot Tishler at dothill dot com>
- Date: Tue, 27 Mar 2001 09:10:00 -0500
- Organization: Dot Hill Systems Corp.
While testing Rob Collins pthread support with the 2001-03-25 snapshot,
I noticed that libm.a and libc.a were *not* symlinks to libcygwin.a as
has been the case up till 1.1.8-2. Is this an inherent difference
between snapshots and releases? Or, will 1.3.0 and later be this way too?
The reason why I'm bring this up is that when -lm is supplied during
linking and libm.a is *not* a symlink to libcygwin.a, then one will
get link errors such as the following:
gcc -shared -Wl,--enable-auto-image-base \
-Wl,--out-implib=libpython2.1.dll.a -o libpython2.1.dll \
Modules/getbuildinfo.o ... -lm
/usr/lib/libcygwin.a(ds00023.o)(.text+0x0): multiple definition of `__infinity'
/usr/lib/libm.a(s_infconst.o)(.text+0x0): first defined here
IIRC, Cygwin binutils had been fixed to tolerate (i.e., ignore)
superfluous -lc and -lm options. If so, then it seems that this only
works when libm.a and libc.a are symlinks.
Thanks,
Jason
--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple