Mail Archives: cygwin-developers/1999/08/20/19:07:03
On Fri, Aug 20, 1999 at 05:58:56PM -0500, Mumit Khan wrote:
>Chris Faylor <cgf AT cygnus DOT 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
- Raw text -