Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com From: Chris Faylor Date: Fri, 8 Sep 2000 11:55:12 -0400 To: cygwin developers Subject: Re: -lc and -lm Message-ID: <20000908115512.E11894@cygnus.com> Reply-To: cygwin-developers AT sources DOT redhat DOT com Mail-Followup-To: cygwin developers References: <20000908123517 DOT 25018 DOT qmail AT web124 DOT yahoomail DOT com> <4 DOT 3 DOT 1 DOT 2 DOT 20000908095342 DOT 01f2ef88 AT pop DOT ma DOT ultranet DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.6i In-Reply-To: <4.3.1.2.20000908095342.01f2ef88@pop.ma.ultranet.com>; from lhall@rfk.com on Fri, Sep 08, 2000 at 09:58:30AM -0400 On Fri, Sep 08, 2000 at 09:58:30AM -0400, Larry Hall (RFK Partners, Inc) wrote: >Date: Fri, 08 Sep 2000 09:58:30 -0400 >To: cygwin developers >From: "Larry Hall (RFK Partners, Inc)" >Subject: Re: -lc and -lm >In-Reply-To: <20000908123517 DOT 25018 DOT qmail AT web124 DOT yahoomail DOT com> > >At 08:35 AM 9/8/2000, Earnie Boyd wrote: >>Back in B18 when I started using Cygwin these libraries were stub libraries. >>Is there a reason that they shouldn't be stub libraries instead of symlinks to >>cygwin runtime? > >Good question. I remember a discussion on the topic of exactly what form >these libraries should take in Cygwin back a long time ago. I believe it >was Mumit who suggested that these libraries could (and should) be symlinks >(I may not be remembering this correctly.) Anyway, its my impression that >having libm.a and libc.a be symlinks to libcygwin.a is sufficiently >problematic that it makes sense to explore other options. > >There. Now that we have my opinion, someone can go ahead and fix the >problem!;-) What does "problematic" mean? The reason for making them something other than stubs is that some packages search for symbols there. IF they are empty libraries there won't be any symbols to search for. cgf