This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight
- To: Chris Faylor <cgf@cygnus.com>
- Subject: Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight
- From: Mumit Khan <khan@xraylith.wisc.EDU>
- Date: Fri, 20 Aug 1999 17:58:56 -0500
- cc: cygwin-developers@sourceware.cygnus.com
Chris Faylor <cgf@cygnus.com> writes:
>
> So, what do you think? Should we just provide a dummy libc.a and
> libm.a? I think that it will be clearer what's going on if there is a
> symbolic link, won't it?
>
> Otherwise, we'll be getting messages like:
>
> "My libc.a is only 14 bytes. I think that's why I'm getting syntax errors
> in my source file."
I honestly don't know what's better. Users are used to seeing Unix systems
symlink libc and libm, so it won't be surprise to anyone. Dummy ones have
the added advantage that they'll work "natively" (symlinks are not visible
outside the emulation of course).
My two second response (have to run) --
pro:
- using ld (as opposed to gcc) will work as expected. Lots of configure
script will run `ld ... -lc' etc. I consider it bad practice in
general, but it's out there. This currently doesn't work either.
con:
- non-cygwin apps can't look inside libc.a or libm.a. This may or may
not be an issue, but something to think about.
For a few 100k extra disk space, we could just hard link it (which will
eventually not copy when Cygwin supports native hard linking).
Principle of least surprise should be our goal.
Regards,
Mumit