Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Fri, 20 Aug 1999 19:06:41 -0400
From: Chris Faylor <cgf AT cygnus DOT com>
To: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>
Cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight
Message-ID: <19990820190641.B7299@cygnus.com>
Mail-Followup-To: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>,
	cygwin-developers AT sourceware DOT cygnus DOT com
References: <19990820184852 DOT B7062 AT cygnus DOT com> <199908202258 DOT RAA06974 AT mercury DOT xraylith DOT wisc DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <199908202258.RAA06974@mercury.xraylith.wisc.edu>; from Mumit Khan on Fri, Aug 20, 1999 at 05:58:56PM -0500

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