delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/02/18/22:38:29

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3E502835.7060400@ece.gatech.edu>
Date: Sun, 16 Feb 2003 19:09:25 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Max Bowsher <maxb AT ukf DOT net>
CC: cygwin <cygwin AT cygwin DOT com>
Subject: Re: [avail for test] libtool-devel-20030121-1
References: <001201c2d5c2$68cd4550$755f07d5 AT BRAMSCHE> <3E500500 DOT 2080905 AT ece DOT gatech DOT edu> <01ce01c2d608$fd8a0ac0$78d96f83 AT pomello>
In-Reply-To: <01ce01c2d608$fd8a0ac0$78d96f83@pomello>

Max Bowsher wrote:

>>>
>>>But, that's neither here nor there.  IF these crossbreed implibs are
> 
>                                                  ^^^^^^^^^^^^^^^^^^
> libuuid.a at least is static *only* - not crossbreed. So there really is no
> way for libtool know to allow it except by name.

Ugh.  You're right -- I was confused by the implicit rules in 
winsup/w32api/lib/Makefile.in.  libkernel32.a and libshell32.a are 
crossbreeds, but the others (libscrnsave.a, libscrnsavw.a, 
liblargeint.a, and libuuid.a) are pure static. [The rest are pure import].

I really really REALLY don't want to special case this. I was able to 
avoid special-casing the compiler runtimes, by using libtool's existing 
ability to parse the output of gcc -nostdlib, and compare it to the 
"normal" link command to determine what libraries are, in fact, compiler 
runtimes.

Newer libtools (e.g. newer than the 20030121 release) allow compiler 
args to be passed in the CC variable, but not linker args thru the LD 
variable.  This means there can be no easy solution ("turn libuuid.a 
into a DLL and import lib; set LD='ld --enable-runtime-pseudo-reloc'; 
and then run libtool").  Sigh.

The only alternatives for this particular problem seem to be:

1) punt.  If you want -luuid, grab the single source file 
winsup/w32api/lib/uuid.c, and add it to your project's source.  Or, 
messier, in your own makefile locate the system's libuuid.a, ar -x it, 
and include the resulting .o directly into your dependencies. You could 
be clever by (basically) recreating libuuid.a as a convenience (static) 
library within your project; then libtool wouldn't complain and you 
could still say -luuid (only, it would have -L<srcdir> in front of it).

2) delay.  --enable-runtime-pseudo-relocs will be the default **on 
cygwin** someday (never on mingw).  Wait until then, or push it now.  In 
any case, once it is the default, then we can simply dllize libuuid, and 
then -luuid will grab the import library, and libtool will be happy. 
But this can never be the solution for mingw.

3) kludge.  Put a special-case exception for -luuid and libuuid.a -- and 
the other four !@#$!@# static libs in w32api -- into the libtool code.

4) revoke the libtool policy; DLLs with static dependencies are just dandy.

All four alternatives suck.  #4 is the worst; it won't happen.  #2 won't 
help mingw.  That leaves #1 and #3 -- and I hate kludges.  How important 
is this?  Is "punting" really such a bad idea?

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019