Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Message-Id: <199908202258.RAA06974@mercury.xraylith.wisc.edu> To: Chris Faylor cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight In-Reply-To: Your message of "Fri, 20 Aug 1999 18:48:52 EDT." <19990820184852 DOT B7062 AT cygnus DOT com> Date: Fri, 20 Aug 1999 17:58:56 -0500 From: Mumit Khan Chris Faylor 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