libtool-patches
[Top][All Lists]
Advanced

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

name.lib vs. -lname (was: Re: msvs support)


From: Peter Ekberg
Subject: name.lib vs. -lname (was: Re: msvs support)
Date: Tue, 14 Feb 2006 11:38:28 +0100
User-agent: Mutt/1.5.11

Hi Ralf!

On Sun, Feb 12, 2006 at 11:17:04AM +0100, Ralf Wildenhues wrote:
> | @@ -4082,6 +4127,17 @@
> |           *) tmp_libs="$tmp_libs $deplib" ;;
> |           esac
> |           ;;
> | +       -l*)
> | +         if test "X$with_gcc" != Xyes; then
> | +           case $host_os/$linkmode in
> | +           mingw*/prog | cygwin*/prog)
> | +             # assume MSVC
> | +             deplib=`$ECHO "X${deplib}.lib" | $Xsed -e 's/^-l//'`
> 
> See above (func_stripname).  I still don't like this `lib' special
> casing at all.  It should equally apply to GCC.  Also with_gcc != yes
> should not imply MSVC.
> 
> I also believe this is not the right place to fix this at all.  It
> should be done at the start of the deplib search algorithm.  I am
> very reluctant to change that part before 2.0.

The rationale is to keep the -lname form as long as possible so
that libtool sees normal stuff as long as possible. If you do
the conversion to name.lib earlier, you have to add handling
for that form in other places where the -lname form is
currently expected. It quickly became a mess when I tried it.
That said, I might have started at the wrong spot and that was
the cause of the mess, as my libtool-fu is weakish.

Heck, I'm not even sure where "the start of the deplib search"
is. Yes, I can take a guess, but I'm really mostly fumbling.

But the comment about gcc is wrong, I think. There are no
libraries named name.lib when you are using gcc, and it expects
-lname so there is no need to mangle the deplib. Or what did you
mean?

Cheers,
Peter




reply via email to

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