Re: Will libm.a always be a symlink? (or snapshot vs. release)

[Christopher Faylor <cgf at redhat dot com>]

On Tue, Mar 27, 2001 at 09:10:00AM -0500, Jason Tishler wrote:
>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?

It's an inherent difference between snapshots and releases.  I fixup the
links when I build a net release.

>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.

Since libm.a, libc.a, and libcygwin.a are all different files, DJ's
changes don't apply here.  The safest thing to do is to reimplement the
symbolic links yourself.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple