[PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)
* tests/cwrapper.at: Add new test 'cwrapper and installed shared libraries.' --- This patch was actually proposed by Roumen Petrov here: http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html He mentioned here: http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg
Re: [cygwin] cwrapper emits wrapper script
egressions. > Conversely, if GCC retains the policy of updating its Libtool files at > most once every decade, then we can't help them, no matter what bug > we're talking about. Right. The problem was that they had modified their local version of libtool-1.4.x, and were theref
Re: mdemo ltdl failure
On Wed, 25 Apr 2007 23:57:13 +0200, "Bruno Haible" <[EMAIL PROTECTED]> [Lots of good comments...snipped] As I was the originator of this change (though not its final form), and because Ralf has already committed it to libtool cvs, I'll generate and test an additional pat
Re: New libtool is in the GCC and Src trees.
gcj uses libltdl primarily as a > portable wrapper for dlopen. As such it works just fine as is. Well, it /did/ -- until the new-libtool merge. Now there seem to be build problems. So /something/ needs fixin'. > Also, > libgcj has some local libltdl patches as well. Then they sh
Re: [cygwin] cwrapper emits wrapper script
On Wed, 06 Jun 2007 09:43:50 -0500, "Peter O'Gorman" said: > I'm lazy and would like to avoid work as much as possible, Gary has > already asked if you'd like a commit bit, I'm hoping you'll agree, then > all we'll need to do is say "ok" and you can commit your changes > yourself. As long as someb
Re: [Patch] cwrapper invokes target directly
e difficulties and ripples are why I originally thought 'eliminate the wrapper script entirely for $host=cygwin|mingw' was a libtool-2.4 project. However, the current libtool-2.2 behavior was an unreported (!) regression over 1.5.x, and the conversation last week seemed to imply that it wa
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
n, and only when done I asked myself > this, more radical question: we go great lengths here to find out a > name. Iff we have a *.la file to go with the implib, can't we just > *know* the name? I mean, we produced that thing, it has the expected > name, no? That's what the
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
jects that are then linked in to the executable (or DLL). With binutils, you can instead create a second file with the following content: 1 24 MOVEABLE PURE ".manifest" and then $ windres .rc .rc.o $ ld -o .exe .exe .rc.o $ mv .exe .exe But that's overkill for the libtool cwrappers
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
generate the manifest file all by itself, regardless of > > executable name. My gripe was that any file created by libtool will > > overwrite the file generated by cl.exe and I think cl.exe will do > > a better job of creating the manifest. My msvc patches then has code > >
Your message to Libtool awaits moderator approval
Your mail to 'Libtool' with the subject (no subject) Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the m
The results of your email commands
The results of your email command are provided below. Attached is your original message. No commands were found in this message. To obtain instructions, send a message containing just the word "help". - Done. --- Begin Message --- --- End Message ---
[PATCH] Move mlibc case matches above GNU/Linux (and similar) ones.
2025-04-27
Thread
mintsuki via Patch submission list for the GNU libtool shared library maintenance tool
>From d08633958d24d4616e5511dee7b06b63d712f0ab Mon Sep 17 00:00:00 2001 From: Mintsuki Date: Sun, 27 Apr 2025 21:01:12 +0200 Subject: [PATCH] Move mlibc case matches above GNU/Linux (and similar) ones. This allows a *-linux-mlibc host to correctly match with the mlibc userland rather than having
[PATCH] doc: Explain how to specify library dependencies
2025-05-06
Thread
Bruno Haible via Patch submission list for the GNU libtool shared library maintenance tool
Hi, Yesterday I spent several hours trying to understand why this libtool invocation: /bin/sh ../libtool --tag=CC --mode=link /Users/runner/work/ci-scratch/ci-scratch/macos-compile clang -g -O2 -no-undefined -version-info 0:0:0 -rpath /usr/local/lib -L/Users/runner/lib -o libintl_m2.la