libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [4/11] Native MSVC support (file-magic-glob)


From: Charles Wilson
Subject: Re: [4/11] Native MSVC support (file-magic-glob)
Date: Wed, 18 Jul 2007 22:55:28 -0400
User-agent: Thunderbird 1.5.0.12 (Windows/20070509)

Peter Rosin wrote:
On Tue, Jul 17, 2007 at 06:48:38AM -0600, Eric Blake wrote:
I still think searching for libs case-insensitively on cygwin is wrong -
the philosophy of cygwin is to be a Linux emulation, where case matters;
and even though you can't have dual case files without a managed mount, it
just seems like perpetuating problems if cygwin allows a library with the
wrong spelling.  For mingw, on the other hand, the goal is indeed to be as
accomodating to Windows as possible, so having libtool ignore case in
library searches on mingw seems like it might be acceptable (although I
have not reviewed your patch for its technical merits).

I do not really care one way or the other for this patch and cygwin, but
I will say this. The only thing that will happen (if I got it right) is
that libtool will refuse to build a shared lib due to missing deps (and
-no-undefined). With this nocaseglob patch, libtool will build a shared
lib. The .la file will continue to list -lfoo as a dep even without the
patch so whoever uses the lib will still link with the Foo shared lib
in the end.

All this of course assumes non-managed mounts.

It is easy enough to exclude cygwin from it, but should I?

I think cygwin should be excluded; Eric is persuasive -- and has thought a lot harder about these tricky filename corner cases on cygwin than anyone else.

The only exception would be if one were using cygwin to drive a mingw or msvc compiler that is expected to be case-insensitive. But in that case, you're really doing a cygwin->mingw/msvc cross, so the $target isn't cygwin at all (and if your test is predicated on $host not $target, then perhaps the "Dear end-user, do not be stupid" rule applies in this case. After all, a linux->mingw cross compiler would ALSO fail given FOO.lib when expecting -lfoo.)

IMO, if your

 s/[aA]/[aA]/g;s/[bB]/[bB]/g;<22 more>;s/[yY]/[yY]/g;s/[zZ]/[zZ]/g;

is the fastest of the alternatives presented, I'd recommend going ahead with it for mingw|pw32, but exclude cygwin. However, the ultimate decision is up to the maintainers.

--
Chuck




reply via email to

[Prev in Thread] Current Thread [Next in Thread]