Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight

[Chris Faylor <cgf@cygnus.com>]

On Fri, Aug 20, 1999 at 05:58:56PM -0500, Mumit Khan wrote:
>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).

I don't think that's a big deal, though.

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

This is a pretty big pro.  If a configure script can find the right stuff
in a libc.a then this is a big win.

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

I don't think we should worry about this.  I'm talking about providing
a Cygwin distribution.  I don't care if something else breaks.

>For a few 100k extra disk space, we could just hard link it (which will
>eventually not copy when Cygwin supports native hard linking).

Cygwin does support hard linking on NT.  On 95/98, I think we'd find
that libc.a would get out of sync with libcygwin.a.

>Principle of least surprise should be our goal.

Yup.  If I have to do this I want to *eliminate* this headache not
just make it slightly less painful.

cgf