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: <003401c2d625$50178d50$78d96f83@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: "cygwin" <cygwin AT cygwin DOT com>
References: <001201c2d5c2$68cd4550$755f07d5 AT BRAMSCHE> <3E500500 DOT 2080905 AT ece DOT gatech DOT edu> <01ce01c2d608$fd8a0ac0$78d96f83 AT pomello> <3E502835 DOT 7060400 AT ece DOT gatech DOT edu>
Subject: Re: [avail for test] libtool-devel-20030121-1
Date: Mon, 17 Feb 2003 01:38:46 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Charles Wilson wrote:
> Max Bowsher wrote:
>>>> But, that's neither here nor there.  IF these crossbreed implibs
>>                                                 ^^^^^^^^^^^^^^^^^^
>> 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.

Besides, this means altering the platform to suit libtool. Talk about the
tail wagging the dog!

> The only alternatives for this particular problem seem to be:
>
> 1) punt.

Well, it's not like we've got many complaints about this.

> 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.

And, as I say above, is ridiculous. Libtool is supposed to assist
portability - no force platforms to redesign themselves.

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

Messy.

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

I like it. But it's not going to happen. So:
How about a flag, like -no-undefined ?
For example: -i-know-what-i-want-to-link-dont-interfere-please :-)

> 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?

Punting is acceptable, if necessary. What do you think about my flag idea?

Max.


--
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/