[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/msg00222.html
that 69e77671 would actually fix the error exposed by this test. I
ran this test both with and without 69e77671; without 69e77671 this
test fails (cygwin), but with it the new test passes. Examination
shows that Roumen's test is exactly what is needed to verify that
the problem fixed by 69e77671 does not regress; his test explicitly
verifies that a newly built DLL (more generally, shared library)
is used at runtime in preference to an installed version.
tests/cwrapper.at | 70 +
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index 248c0c0..ff3d04f 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -134,3 +134,73 @@ done
AT_CLEANUP
+
+AT_SETUP([cwrapper and installed shared libraries])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' && exit 77],
+[1], [ignore])
+
+# FIXME with shared_fails for this test on AIX
+# copy from link-order2.at:
+eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|allow_undefined_flag)='`
+
+undefined_setting=-no-undefined
+shared_fails=no
+case $host_os,$LDFLAGS,$allow_undefined_flag in
+aix*,*-brtl*,*) ;;
+aix*) shared_fails=yes ;;
+darwin*,*,*-flat_namespace*) undefined_setting= ;;
+darwin*,*,*) shared_fails=yes ;;
+esac
+# end of copy from link-order2.at
+
+LDFLAGS="$LDFLAGS $undefined_setting"
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# we must build foo library in a separate directory to avoid on some
+# platforms shared library to be loaded from "current" directory
+
+mkdir foo
+cd foo
+# build and install "old" library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(1); }
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
+$LIBTOOL --mode=install $lt_INSTALL liba.la $libdir
+
+# build a new library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(2); }
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
+
+cd ..
+
+# build and run test application
+AT_DATA([m.c], [[
+extern int liba_ver (void);
+int main (void)
+{
+ int r = (liba_ver () == 2) ? 0 : 1;
+ return(r);
+}
+]])
+
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la
+LT_AT_EXEC_CHECK([./m1], [0], [ignore], [ignore], [])
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m2$EXEEXT m.$OBJEXT foo/liba.la
-L$inst/lib
+LT_AT_EXEC_CHECK([./m2], [0], [ignore], [ignore], [])
+
+AT_CLEANUP
--
1.7.1
Re: [cygwin] cwrapper emits wrapper script
On Wed, 25 Apr 2007 23:01:10 +0200, "Ralf Wildenhues" > FWIW, this isn't going to change a lot for me. If I have doubts that > changes are free of regressions, then there is work to be done. agreed. > It's > not helpful if GCC developers have to sort out those regressions. > 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 therefore nervous about upgrading and losing those "fixes". Plus, they had to update autoconf from 2.13 and automake from 1.[4p5|7|8,depending] throughout, first -- and that took a while. A looog while. However, similar problems should be avoided in the future, because from what I understand, the new rules are: either use an official, unpatched, released version of external tools (like libtool), or use an unpatched version taken directly from the external development tree. The only problem I see is if libtool-HEAD-after-2.0 (say, nearing the /next/ major release) begins requiring ac-2.61/am-1.10 (or even newer). Then gcc would be stuck with their unpatched snapshot of libtool-HEAD from before that new libtool requirement, until they updated ac/am. I suspect they will make more of an effort to keep up with current autotools, plus I think any future ac/am updates will be much less, err, issue-prone than the ac-2.13/ac-2.5x transition was. > Primary aim is to release Libtool 2. Effectively you are suggesting > that Cygwin's "transparent_exe" feature, its argz bug, and the MinGW > breakage of cwrapper be considered release blockers. The latter two, yes: see below. The first one: no. Only, if you ARE going to accept it before 2.0, then I'd prefer to get that done before the upcoming gcc import, rather than miss it by a few days. If you're NOT going to accept it pre-2.0, or if it takes a month to stabilize and we miss the gcc "deadline" by _weeks_, then no problem. > Which I personally don't have a problem with, especially if you're the > one doing all the hard work and effectively end up doing the maintenance > as well. ;-) But I think that should be noted. And the next time you > cry about the release process being ever slower, I'll remind you of this > point. ;-) I call shenanigans. The argz stuff notwithstanding, the very idea of fixing the "transparent_exe" issue &etc was rejected by me a year ago as being too destabilizing for 2.0(.0), which was due Real Soon Then. http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html "Sadly, it's too late for any such major change to get into libtool-2.0[ed: 2.0.0 initial release] because libtool is effectively in code-slush right now. But, if *somebody* implements this fix I'll put it in cygwin's dist of libtool-2.0 and push for it to go into libtool-2.0.x.[ed: x > 0]" It was rejected AGAIN by me two weeks ago as being too destabilizing for 2.0: http://cygwin.com/ml/cygwin/2007-04/msg00543.html "Caveat: over a year after the message referenced above, but libtool2.0 is STILL in code-slush, so the desired fixes will have to wait until after 2.0." It was you who said in response, last week: http://cygwin.com/ml/cygwin/2007-04/msg00549.html "... I'd prefer to see such a patch before deciding when it's good to put it in." So, I began feeding those patches. I was surprised when you accepted in principle -- and then actually committed -- the first "use functions to emit wrapper code" patch without even seeing the others. Despite my surprise, I continued feeding the others, because if one of the three patches was actually accepted, code slush or no, then I really didn't want the official libtool-2.0(.0) to have only a partly finished implementation (only one of the three phases). Granted, I have implemented all three phases with only backwards-dependence: HEAD+phase1-only works. HEAD+phase1-and-phase2-only works. HEAD+all-three-phases works. There's no functional breakage by taking only phase1, or only phase1 and phase2. But it strikes me as odd to do so, else why take phase 1 at all? Note that my original email, from last year, actually specified three separate phases, and strongly implied that they would each be implemented separately (e.g. three separate patches) -- although my implementation, and theory-of-operation, of #2 was a bit different than I originally proposed, causing #3 to differ as well. But that's beside the point. The argz stuff: actually fixes a _bug_ that was exposed by failing mdemo tests on cygwin, which began failing ~six months ago (I no longer remember exactly when, nor what change in either libtool or cygwin was the proximate cause; perhaps cygwin fi
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 patch addressing Bruno's concerns. Then Ralf can propagate the update over to the gnulib folks. > Also, I don't see where in the C code this macro SYSTEM_ARGZ_IS_BROKEN is > being tested. It is being used on the libtool side in libltdl/libltdl/lt__glibc.h: -#if !defined(HAVE_ARGZ_H) +#if !defined(HAVE_ARGZ_H) || defined(SYSTEM_ARGZ_IS_BROKEN) /* Redefine any glibc symbols we reimplement to import the implementations into our lt__ namespace so we don't ever clash with the system library if our clients use argz_* -- Chuck
Re: New libtool is in the GCC and Src trees.
On Tue, 29 May 2007 12:36:13 -0600, "Tom Tromey" said: > >>>>> "Charles" == Charles Wilson writes: > Charles> Secondly, the entire contents of libjava/libltdl/ need to be > Charles> updated. > > I don't think we need to do this. libgcj 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 should be submitted upstream -- if they are still necessary. There have been a lot of improvements in libltdl since 1.4.x and even 1.5.x. > Why do you think it should be updated? Because unless I am very mistaken, new libtool.m4 + old ltdl.m4(&other old libltdl stuff) is not a tested/supported configuration -- it /may/ work, but... Will aclocal pull in the the old libtool.m4 (perhaps from /usr/share/aclocal/ if it can't find one with the required serial number closer at hand?) at the request of the old ltdl.m4? Will it instead complain about serial number mismatch? Will libjava/aclocal.m4 end up with both/conflicting versions of various LT macros, or worse a hodgepodge of some LT macros from old libtool.m4 and some from new libtool.m4? Or will libjava/aclocal get only new libtool.m4 LT macros, but not define some of the (old) ones that old ltdl.m4 relies on? I don't know the answers to these questions -- but I do know that new libtool.m4 + new libltdl stuff has a pretty thorough test suite. I hate to say this, but perhaps, for now: (1) the libjava/ portions of Steve's patch should be backed out (2) local copies of what USED to be in put into libjava/ (3) libjava's configure.ac and Makefile.am's modified again to NOT look in (4) re-auto* in libjava/* just so that libjava can get back to status quo ante. Because it looks like there really is a whole lot of work left to be done before libjava is ready to use the new libtool, thanks to the overlooked use of libltdl. -- Chuck
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 somebody other than me inspects/approves (...or rejects) my patches, I'm happy to turn the crank to check them in myself. -- Chuck
Re: [Patch] cwrapper invokes target directly
On Wed, 30 Apr 2008 10:12:36 -0500 (CDT), "Bob Friesenhahn" said: > I have a MinGW cross-compiler hosted off of FreeBSD 7.0. Presumably I > can run Wine on it. I know that Linux has special hooks in order to > automatically run Windows executables using Wine. Is the Wine > execution support dependent on this Linux feature? No, the compile phase requires the $build (linux, unix?) executable 'winepath' only, and does not rely on the binfmt extension present in linux. The wrapper itself is already running in the emulation environment, and uses Win32 spawnv (and other functions from the win32 C runtime library) to launch the target executable -- within the same emulation env, so no need for binfmt there, either. However, actually running the test suite is going to try to invoke the wrapper.exe, so that would require binfmt (or another solution; I have ideas). This may (or may not) represent a regression from 1.5.x+explicit $TARGETSHELL specification, I'm not sure. When I (later) add support for $build=*nix+wine, $host=cygwin cross-compiles, I'll also need either the 'wine' executable (which itself is a $build=*nix program) or the binfmt extension, because I need to execute 'cygpath' *in the $host environment* for step 2 of the following conversion: *nix [$build] path --( winepath )--> native win32 [$host] path --( 'cygpath -u' under wine )--> cygwin [$host] path All of these 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 was important enough to try to fasttrack before 2.4...but that doesn't mean it will or can get completely fixed in one simple patch. It may require iteration and public testing -- over a few 2.2.x releases -- before we get it right. :-( -- Chuck
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
On Thu, 13 Nov 2008 22:09:07 +0100, "Ralf Wildenhues" said: > OK, how about this. It is a slight backward incompatibility, but > not a large one: > - --verbose undoes --silent *and* enables verbose output (that one with > func_verbose), > - --no-silent *only* undoes --silent, > > It should still be bearable for the user, in the sense that if you > use --verbose rather than --no-silent, it's not a big problem. > And we don't have to think about what > --verbose --verbose --silent > > causes, we can just make the last one win. > > If you agree, then let's proceed this way. I don't mind who writes the > patch. That sounds good to me. The help output would need a little re-wording: # --quiet, --silentdon't print informational messages # -v, --verboseprint informational messages (default) # --no-silent ??? I'll let you do that. > > >> B) func_win32_libid() gives some confusing errors to users > > >>when (a) using recursive make, and (b) MAKEFLAGS does not > > >>contain $OBJDUMP. Add a diagnostic error message, rather > > >>than allowing $SED to die a horrible death. > [...] > > Actually, this may no longer be necessary given the _LT_DECL_OBJDUMP > > changes (I /said/ this was an old patch). Here's the thread: > > http://cygwin.com/ml/cygwin/2008-09/msg00552.html > > Ah, ok, thanks. I'll remove any of these bits from the revised patch(es). > > Well, one reason I sat on this for so long was the 'fallback' mechanism > > for deducing the dll name from the import library was just so...hideous. > > And it wasn't a fallback -- it was the only mechanism since I hadn't yet > > enhanced dlltool. > > Do you steer dlltool development, BTW? No. I've contributed a few patches over the years to dlltool and binutils, but that's it. > > The only reason to allow it is because (hopefully) that ugly fallback > > code can get flagged with a warning, and maybe in a year or so get > > removed. > > Sounds like a good idea. Of course, first I need to revise the dlltool patch and get it accepted; there have been some comments on the binutils list. > > Well, that, and it fixes a test that currently fails. > > Which one, and can you post output for failure as well as success with > the patch, please? demo-exec after demo-shared, in the old test suite. I'll post the output(s) tonight or tomorrow. > Hmm. I reviewed this whole function, 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 *.la file was designed for: to not have to > look into the binary files for information. > > Or is this purely for import libraries not created with libtool (and > people who throw away *.la files)? The information (e.g. library to dlpreopen) is passed in $dlprefiles. But, if that filename is .la: func_mode_link(): ... dlfiles|dlprefiles) if test "$preload" = no; then # Add the symbol object into the linking commands. func_append compile_command " @SYMFILE@" func_append finalize_command " @SYMFILE@" preload=yes fi case $arg in *.la | *.lo) ;; # We handle these cases below. ... ...much later... *.la) # A libtool-controlled library. if test "$prev" = dlfiles; then # This library was specified with -dlopen. dlfiles="$dlfiles $arg" prev= elif test "$prev" = dlprefiles; then # The library was specified with -dlpreopen. dlprefiles="$dlprefiles $arg" prev= else deplibs="$deplibs $arg" fi continue ;; So far, so good. But then we eventually source the .la file, and end up here (this is, in fact, what's happening in the demo-shared case): # This library was specified with -dlpreopen. if test "$pass" = dlpreopen; then if test -z "$libdir" && test "$linkmode" = prog; then func_fatal_error "only libraries may -dlpreopen a convenience library: \`$lib'" fi # Prefer using a static library (so that no silly _DYNAMIC symbols # are required to link). if test -n "$old_library"; then newdlprefiles="$newdlprefiles $dir/$old_library" # Keep a list of p
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
On Tue, 30 Jun 2009 16:23 +0200, "Ralf Wildenhues" wrote: > * Charles Wilson wrote on Tue, Jun 30, 2009 at 02:05:47PM CEST: > > * libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New function. > > (func_mode_link) [cygwin|mingw]: Create manifest files for wrapper > > and target exe when target name matches heuristic that triggers > > UAC problems for newer win32 OSs. > Can you explain what the semantics for UAC files are (pointer is > sufficient)? On Vista and newer, applications whose names match certain patterns (yay for security!) are automatically assumed to be installers, and when launched trigger Vista's User Account Control (e.g. privilege elevation prompt). However, in many cases you don't WANT privelege elevation -- why should the BSD-flavor install.exe require Administrator privileges when you do a "make install prefix=/home/my-stuff"? So, you can add a manifest file with the same name as the executable, following a specified template [*], that suppresses the privelege elevation prompt. These manifests need not be separate files. MSVC provides a special tool that can compile them into resource objects 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, and probably also for most other executables... http://cygwin.com/ml/cygwin/2006-12/msg00518.html (and thread) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1020271&SiteID=1&mode=1 (and thread) And remember, you only NEED manifests at all if your application's NAME matches certain patterns that "look like" they might be installers. Yeesh. > Why does gcc but not msvc need them? It does. cl.exe has a flag that causes it to automatically invoke the MSVC manifest tool (mt? I forget), AND link the resulting object into the target. Peter's libtool patches exploit this functionality, which is why he *doesn't* want libtool to create external xml manifests for that toolchain. > Can you convey the need for copyright assignment requirements for > nontrivial patches? [*] The bulk of the patch is a template: there is only one way to format this manifest to accomplish the goal. Thus, the creative content of the patch is about 7-8 lines, so it's still a (tiny change) IMO. But IANAL, so... > Can you explain why automake should not need support for UAC files, > and if it does need them, in what cases? (Note I'm not asking you > to write a patch.) It probably should -- but the rules are very different, even require different tools, depending on the toolchain in use. AND sometimes you want external xml manifests, other times (if your toolchain supports it) you want compiled-in resources. AND you only ever need them if the Windows version is Vista or above AND the target filename matches certain patterns. I'm not sure that we can yet formulate the correct procedure, in order to codify it as "The Way" that automake should do it. This is why Yaakov took the easy way out: for the magic executable names, just always create in-place external xml manifests and don't even bother to install them -- because they are not always needed on the destination system, even if they may be needed on the build system. -- Chuck
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
On Wed, 01 Jul 2009 18:55 +0200, "Ralf Wildenhues" wrote: > * Peter Rosin wrote on Wed, Jul 01, 2009 at 09:05:53AM CEST: > > >On Tue, 30 Jun 2009 16:23 +0200, "Ralf Wildenhues" wrote: > > >>Why does gcc but not msvc need them? > > > cl.exe will 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 > > to embed the manifest into the executable using mt (manifest tool), > > but that is immaterial to this discussion. > > Have you guys considered adding manifest file functionality to GCC? I haven't. Frankly, I'd rather see 4.x stabilize on cygwin with the current feature set, than try to add new ones right now. The reason cl.exe has the manifest functionality built in, is because as of VS2005, the runtime library (be it msvcrt80.dll, or msvcrp80.dll, or whatever) is NOT identified, located, and loaded based on its name and the path search rules we all know and love. Instead, a manifest resource is used to determine EXACTLY which patch-level version of the non-interoperable versions of msvcrt80.dll is required by the application (as identified by a GUID in the resource). You can have many different versions installed in "SxS" (side by side) directories under C:\Windows\, and none of them need (or should) be in your PATH. This is Microsoft's "solution" to DLL hell. [no comment...] For gcc, we don't *NEED* manifests for every single pe[i]-i386 image. We only "need" them for a small selection of unluckily-named exes, and then only when they are executed on Vista or above. -- Chuck
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 moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.gnu.org/mailman/confirm/libtool/30b6232edd38efd3f15a33fbeb7536a18d33e3c7
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 the GNU/Linux (and similar) userland match override it.
---
m4/libtool.m4 | 70 +--
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 99b53ad0..4b4ea721 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2929,6 +2929,18 @@ irix5* | irix6* | nonstopux*)
hardcode_into_libs=yes
;;
+*-mlibc)
+ version_type=linux # correct to gnu/linux during the next big refactor
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='$libname$release$shared_ext$versuffix
$libname$release$shared_ext$major $libname$shared_ext'
+ soname_spec='$libname$release$shared_ext$major'
+ dynamic_linker='mlibc ld.so'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ ;;
+
# No shared lib support for Linux oldld, aout, or coff.
linux*oldld* | linux*aout* | linux*coff*)
dynamic_linker=no
@@ -3040,18 +3052,6 @@ netbsd*)
stdlibflag=
;;
-*-mlibc)
- version_type=linux # correct to gnu/linux during the next big refactor
- need_lib_prefix=no
- need_version=no
- library_names_spec='$libname$release$shared_ext$versuffix
$libname$release$shared_ext$major $libname$shared_ext'
- soname_spec='$libname$release$shared_ext$major'
- dynamic_linker='mlibc ld.so'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=no
- hardcode_into_libs=yes
- ;;
-
newsos6)
version_type=linux # correct to gnu/linux during the next big refactor
library_names_spec='$libname$release$shared_ext$versuffix
$libname$release$shared_ext$major $libname$shared_ext'
@@ -3713,12 +3713,12 @@ irix5* | irix6* | nonstopux*)
lt_cv_deplibs_check_method=pass_all
;;
-# This must be glibc/ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*)
+*-mlibc)
lt_cv_deplibs_check_method=pass_all
;;
-*-mlibc)
+# This must be glibc/ELF.
+linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*)
lt_cv_deplibs_check_method=pass_all
;;
@@ -4541,6 +4541,8 @@ m4_if([$1], [CXX], [
;;
esac
;;
+ *-mlibc)
+ ;;
linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*)
case $cc_basename in
KCC*)
@@ -4607,8 +4609,6 @@ m4_if([$1], [CXX], [
;;
netbsd* | netbsdelf*-gnu)
;;
- *-mlibc)
- ;;
*qnx* | *nto*)
# QNX uses GNU C++, but need to define -shared option too, otherwise
# it will coredump.
@@ -4869,6 +4869,12 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
+*-mlibc)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+ ;;
+
linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*)
case $cc_basename in
# old Intel for x86_64, which still supported -KPIC.
@@ -4965,12 +4971,6 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
;;
-*-mlibc)
- _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
- _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
- ;;
-
*nto* | *qnx*)
# QNX uses GNU C++, but need to define -shared option too, otherwise
# it will coredump.
@@ -5372,6 +5372,11 @@ _LT_EOF
_LT_TAGVAR(archive_expsym_cmds, $1)='$SED "s|^|_|" $export_symbols
>$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags $wl-h,$soname
$wl--retain-symbols-file,$output_objdir/$soname.expsym $wl--image-base,`expr
${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
;;
+*-mlibc)
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags $wl-soname $wl$soname -o $lib'
+ _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $libobjs
$deplibs $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file
$wl$export_symbols -o $lib'
+ ;;
+
gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
tmp_diet=no
if test linux-dietlibc = "$host_os"; then
@@ -5452,11 +5457,6 @@ _LT_EOF
fi
;;
-*-mlibc)
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags $wl-soname $wl$soname -o $lib'
- _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $libobjs
$deplibs $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file
$wl$export_symbols -o $lib'
- ;;
-
netbsd* | netbsdelf*-gnu)
if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
_LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable $libobjs $deplibs
$linker_flags -o $lib'
@
[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 -rpath /usr/local/lib Libintl.lo ../intl/libintl.la
/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc/aarch64-apple-darwin24/14/../../../libm2pim.dylib
results in libtool (version 2.5.4, on macOS) emitting this output
libtool: link: /Users/runner/work/ci-scratch/ci-scratch/macos-compile clang
-dynamiclib -o .libs/libintl_m2.0.dylib .libs/Libintl.o -L/Users/runner/lib
../intl/.libs/libintl.dylib -lpthread -g -O2 -install_name
/usr/local/lib/libintl_m2.0.dylib -compatibility_version 1 -current_version 1.0
It lacks the dependency to .../libm2pim.dylib, and thus produces link
errors for symbols that are in fact provided by libm2pim.dylib:
Undefined symbols for architecture arm64:
"_m2pim_DynamicStrings_InitStringCharStar", referenced from:
_Libintl_Gettext in Libintl.o
_Libintl_DGettext in Libintl.o
_Libintl_DCGettext in Libintl.o
_Libintl_NGettext in Libintl.o
_Libintl_DNGettext in Libintl.o
_Libintl_DCNGettext in Libintl.o
"_m2pim_M2RTS_RegisterModule", referenced from:
__M2_Libintl_ctor in Libintl.o
"_m2pim_M2RTS_RequestDependant", referenced from:
__M2_Libintl_dep in Libintl.o
__M2_Libintl_dep in Libintl.o
__M2_Libintl_dep in Libintl.o
__M2_Libintl_dep in Libintl.o
__M2_Libintl_dep in Libintl.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[5]: *** [libintl_m2.la] Error 1
Ideally, libtool would produce an error message:
link dependencies cannot be given directly as arguments:
/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../lib/gcc/current/gcc/aarch64-apple-darwin24/14/../../../libm2pim.dylib
But barring such a change, here's at least a documentation fix, to make users
like me aware of what the problem is.
>From f71eaf2dbbdfb7ed4f874251705719addc304e72 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Tue, 6 May 2025 17:00:51 +0200
Subject: [PATCH] doc: Explain how to specify library dependencies.
* doc/libtool.texi (Link mode): Explain how to specify dependencies to
already installed libraries.
---
doc/libtool.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 60ddab7a..ba64245e 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1708,6 +1708,11 @@ Pass a linker-specific flag directly to the linker.
Pass a link-specific flag to the compiler driver (@code{CC}) during linking.
@end table
+Note: When the output file shall depend on an installed library, you
+cannot specify the library name as @code{@var{dir}/lib@var{name}.a} or
+@code{@var{dir}/lib@var{name}.so} as part of the @var{mode-args}.
+Instead, pass the arguments @code{-L@var{dir}} and @code{-l@var{name}}.
+
If the @var{output-file} ends in @file{.la}, then a libtool library is
created, which must be built only from library objects (@file{.lo} files).
The @option{-rpath} option is required. In the current implementation,
--
2.43.0
