Re: [sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR
On 19:29 Fri 02 Jul , Tim Mooney wrote: > HOWEVER, if you do a "DESTDIR" install, the relink step for libb will fail, > because libtool doesn't prepend the DESTDIR library directory to the library > search path, so when libb is relinked, it finds the liba from package-1.0 > that's already installed on the system. Since the 1.0 version of liba doesn't > have function "a_2", the relink fails. A relink failure would be a boon in the context of this issue, because the user notices right away that something has gone awry. It can cause subtle problems that don't go noticed until (perhaps much) later. My first encounter with this issue was with cross-compilation, where I ended up with a library that had a shared library dependency on the build system's C library, rather than that of the host system. When I later attempted to build a program that linked against that library, the linker saw this dependency and tried to link the program against both the build and host system's C libraries. The result was an extremely cryptic error message about thread-local storage. When I eventually tracked it down to a particular faulty library, I tried to find out why the library got linked against the build system's C library. This turned out to be very tricky, because the library was perfectly fine at every step _except_ for 'make install', which was taking a perfectly fine library and writing a totally broken library to the install location. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On 2010-08-25 06:40 +0200, Vincent Torri wrote: > What would be nice about the autotools ML is having, in the subject, > the name of the project > in bracket: > > Subject: [libtool] > > That can be done automatically (a configuration option in mailman, I > guess). That would make me more aware of something important to read. Please, no mangling of e-mail subjects. All pain, no gain. See http://www.andrew.cmu.edu/user/qralston/writing/tagging-harmful/ for details. Everything sent by this mailing list has the header: X-BeenThere: libtool@gnu.org which can be used to filter mails from the list. For example, I use the following procmail recipe: :0 * ^X-BeenThere:.*libt...@gnu.org libtool/ which puts all the mails from this list into the 'libtool' mailbox. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 2010-12-20 08:54 -0800, Bruce Korb wrote: > If the default build is 64 bit, why does it make sense that the > default library directory is the 32 bit library? As far as I know, the only reason for this design is to avoid breaking 32-bit proprietary software with /usr/lib paths hardcoded into their binaries. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool
Example in libtool manual gives wrong dependencies w/ automake.
Hello, I'm working on a project which uses libltdl to load modules, and I've set it up in a manner pretty similar to what's described in the libtool manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5). In that section, the manual recommends to use a weak library interface. However, the example given in the manual does not work because the generated makefile lacks dependencies from libloader.la to libinterface.la's objects. Here's a simplified and complete version of the example in the libtool manual: % cat >Makefile.am <<'EOF' lib_LTLIBRARIES = libbar.la libfoo.la libfoo_la_SOURCES = foo.c libbar_la_SOURCES = bar.c libbar_la_LDFLAGS = -weak libfoo.la libbar_la_LIBADD = $(libfoo_la_OBJECTS) EOF % cat >configure.ac <<'EOF' AC_INIT([test], [1.0]) AM_INIT_AUTOMAKE([foreign]) AM_SILENT_RULES([yes]) LT_INIT AC_CONFIG_FILES([Makefile]) AC_OUTPUT EOF % touch foo.c bar.c Attempting to build the above (with autoconf 2.68, automake 1.11.1 and libtool 2.4): % ./configure -q && make CC bar.lo CCLD libbar.la libtool: link: `foo.lo' is not a valid libtool object make: *** [libbar.la] Error 1 Looking at the generated Makefile.in, we see this is because libbar.la doesn't have any dependency on foo.lo. We can add it to the Makefile.am: libbar_la = libbar.la $(libbar_la): $(libfoo_la_OBJECTS) and now it will build. So, should automake support the example in the libtool manual, or does the libtool manual need to be fixed? If the latter, is the above workaround a good one? Thanks, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Example in libtool manual gives wrong dependencies w/ automake.
Hi Ralf, On 2011-04-02 10:42 +0200, Ralf Wildenhues wrote: > * Nick Bowler wrote on Fri, Apr 01, 2011 at 04:04:21PM CEST: > > I'm working on a project which uses libltdl to load modules, and I've > > set it up in a manner pretty similar to what's described in the libtool > > manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5). > > In that section, the manual recommends to use a weak library interface. > > > > However, the example given in the manual does not work because > > the generated makefile lacks dependencies from libloader.la to > > libinterface.la's objects. > > Indeed. The reference to the internal *_OBJECTS variable is surprising. > It would be cleaner to have a libfoo_conv.la convenience > (noinst_LTLIBRARIES) archive that had the same sources as libfoo.la and > add that to libbar_la_LIBADD. > > A patch to fix libtool.texi to this end would be appreciated. Indeed, a convenience library does at least seem like an improvement over what's currently in the manual, irrespective of whether the approach is ideal. I can probably cook up the patch for this when I have some time. > One thing that I wonder about is why you actually need the foo code to > be both in libfoo and libbar. If possible, then code should only ever > exist in one shared library. (I may be missing details from the > dlpreopen machinery here now, it's been a while ... feedback as to what > worked for you appreciated.) I don't know the answer to this question, either. I haven't actually gotten everything working, yet: I was just trying out what the manual suggested and ran into this issue. When/if I get things working I'll let you know, but for now I've put this issue on the back burner so it might be a while. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: inter-library-dependency, how?
On 2011-09-09 17:56 +0200, Christian Rössel wrote: > I want to build a program that depends on a libtool library that depends > on a non-libtool library that needs rpath information to be found a runtime. > > My Makefile.am looks like this: > lib_LTLIBRARIES= libfoo.la > libfoo_la_SOURCES = libfoo.c libfoo.h > libfoo_la_CPPFLAGS = -I/opt/packages/papi/4.1.2.1/include > libfoo_la_LDFLAGS = -L/opt/packages/papi/4.1.2.1/lib > libfoo_la_LIBADD = -lpapi > > bin_PROGRAMS = foo > foo_SOURCES = foo.c > foo_LDADD= libfoo.la [...] > Building and linking succeeds, but trying to run ./foo leads to > ./foo: error while loading shared libraries: libpapi.so: cannot open > shared object file: No such file or directory > > The library is in the location specified by libfoo_la_LDFLAGS (.a and > .so). But the rpath /opt/packages/papi/4.1.2.1/lib is not available. How > do I get it into foo without specifying it as > foo_LDFLAGS = -Wl,-rpath /opt/packages/papi/4.1.2.1/lib? Looking at https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode, -R libdir If output-file is a program, add libdir to its run-time path. If output-file is a library, add -Rlibdir to its dependency_libs, so that, whenever the library is linked into a program, libdir will be added to its run-time path. So it seems that adding -R/opt/packages/papi/4.1.2.1/lib to libfoo_la_LDFLAGS would do the trick? Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: ltdl and C++
On 2011-09-19 15:34 +0200, Alessandro Candini wrote: > Configure and make works but I do not produce a dynamic linked > executable, unlike the original John's example: > ../src $ ldd hello > not a dynamic executable This is normal. When libtool creates an executable that links against other libtool libraries in your source tree, it creates a shell script to run the program in-place so that you don't need to install it. You haven't shown us your Makefile.am, but I assume it contains something like hello_LDFLAGS = -dlopen plugin.la. You appear to be running ldd on that shell script, so of course it's "not a dynamic executable". The actual binary that gets installed is located in .libs/. If you want to run ldd on an uninstalled executable, do it through libtool: libtool --mode=execute ldd hello Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: how do I avoid dynamic libraries?
Hi Sam, This sounds like a libtool question, so I'll Cc the libtool list and try to answer it based on that assumption. On 2012-02-14 10:18 -0500, Sam Steingold wrote: > There is a problem with the libffcall (http://www.gnu.org/software/libffcall/ > http://savannah.gnu.org/projects/libffcall) package (un)maintained by > Bruno Haible, described in <https://bugs.launchpad.net/bugs/274951>: > > -- libffcall should be built without shared libraries as explained in >its README[1] file (most of the code is in headers anyway &c) > > -- when clisp is linked against libffcall's shared libraries it crashes >on self-test > > So, I have two questions: > > 1. how do I modify the libffcall's configure.in[2] so that the shared >libraries are never built even if the user asks for them? If you use LT_INIT([disable-shared]) in configure.ac, then the default will be to not build shared libraries. The user can still enable them explicitly, though. To totally disable generating a shared library, you'll need to link the library using libtool's -static flag (if you're using automake, this probably means adding it to libffcall_la_LDFLAGS). Another option is to not use libtool at all. > 2. how do I modify the clisp's configure.in[3] so that it never finds >libffcall's shared libraries even if they are mistakenly installed? The easiest way is to say "don't do that". Nevertheless, libtool provides the flag -static-libtool-libs to force it to use only static libtool libraries. However, this will affect *all* libtool libraries that you link against. I don't know if possible to link only a subset of the libtool libraries statically. Another option is to not link against the libtool library at all. > > [1] http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/README?root=libffcall > > [2] > http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/configure.in?root=libffcall > > [3] > http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/file/tip/src/m4/ffcall.m4 Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: conditionally disabling libltdl subconfigure
On 2012-08-22 15:12 +0200, Brice Goglin wrote: > I am working at embedding libltdl inside our project (hwloc, an Open MPI > subprojet). Our plugins are not expected to be enabled in the most > common cases. So I am trying to see if the libltdl sub-configure could > be skipped entirely unless really needed (when plugins are enabled, and > libltdl is indeed built). I got the usual failure when I tried to put > LTDL_INIT inside a conditional block so I am looking for something else now. > > Modifying the subdirs variable before AC_OUTPUT seems to work. But this > hack may not be safe enough. Is there a better way to do this? Use either the "recursive" or "nonrecursive" libltdl styles. Do not use "subproject" (the default). Both these styles integrate all the configure machinery directly into your main configure script, so there may still be some extra checks but they should be fairly low-cost in the grand scheme of things (especially compared to subproject!). You can then use Automake conditionals to control whether or not libltdl will be built. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: conditionally disabling libltdl subconfigure
On 2012-08-22 18:32 +0200, Brice Goglin wrote: > Le 22/08/2012 16:32, Nick Bowler a écrit : > > On 2012-08-22 15:12 +0200, Brice Goglin wrote: > >> I am working at embedding libltdl inside our project (hwloc, an Open MPI > >> subprojet). Our plugins are not expected to be enabled in the most > >> common cases. So I am trying to see if the libltdl sub-configure could > >> be skipped entirely unless really needed (when plugins are enabled, and > >> libltdl is indeed built). I got the usual failure when I tried to put > >> LTDL_INIT inside a conditional block so I am looking for something else > >> now. > >> > >> Modifying the subdirs variable before AC_OUTPUT seems to work. But this > >> hack may not be safe enough. Is there a better way to do this? > > Use either the "recursive" or "nonrecursive" libltdl styles. Do not use > > "subproject" (the default). Both these styles integrate all the > > configure machinery directly into your main configure script, so there > > may still be some extra checks but they should be fairly low-cost in the > > grand scheme of things (especially compared to subproject!). > > > > You can then use Automake conditionals to control whether or not libltdl > > will be built. > > > > Cheers, > > Thanks a lot! It looks promising, indeed. > > One small problem with this is that it requires -I$(top_builddir) in > CPPFLAGS since it wants to include LT_CONFIG_H=relative/path/config.h > Not sure how this could be improved. Maybe by passing the absolute path > in LT_CONFIG_H? Or by allowing to manually override it? So you have your config.h in a subdir from the top of your project, e.g., something like AC_CONFIG_HEADERS([some/subdir/config.h]) and libltdl is trying to #include ? That sounds like it might be a libltdl bug. Automake will in this case add -Isome/subdir by default, so libltdl should just be be #including instead (i.e., not specifying any of the leading directories). Other than adding -I$(top_builddir) to CPPFLAGS, as a workaround you could probably add something like this just before AC_OUTPUT (untested): LT_CONFIG_H=`expr "$LT_CONFIG_H" : '.*/\(.*\)'` Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: conditionally disabling libltdl subconfigure
On 2012-08-22 20:26 +0200, Brice Goglin wrote: > Le 22/08/2012 19:44, Nick Bowler a écrit : > > On 2012-08-22 18:32 +0200, Brice Goglin wrote: > >> Le 22/08/2012 16:32, Nick Bowler a écrit : [...] > > Other than adding -I$(top_builddir) to CPPFLAGS, as a workaround you > > could probably add something like this just before AC_OUTPUT (untested): > > > > LT_CONFIG_H=`expr "$LT_CONFIG_H" : '.*/\(.*\)'` > > > > Your analysis looks correct but the workaround doesn't seem to work. It > looks like LT_CONFIG_H is set inside AC_OUTPUT. Indeed, it looks like LT_CONFIG_H is set using AC_CONFIG_COMMANDS_PRE, so it does in fact get set "inside" AC_OUTPUT. I guess you could write AC_CONFIG_COMMANDS_PRE([LT_CONFIG_H=`expr "$LT_CONFIG_H" : '.*/\(.*\)'`]) and hope that it runs after libltdl's registration. Unfortunately, the autoconf manual does not appear to specify the order in which multiple AC_CONFIG_COMMANDS_PRE registrations are run, so this might not be the most robust approach. Perhaps someone on the autoconf list can clarify. It would be prudent to report the issue to the bug-libt...@gnu.org mailing list, ideally with a small test case. Obviously if you can wait for an upstream fix and avoid any hack workarounds for old versions that'd be ideal... Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Setting ACLOCAL_AMFLAGS with ':=' vs '='
On 2014-09-18 09:36 +0100, R. Diez wrote: > If I add this line to my Makefile.am (and I make sure that the 'm4' > subdir is created beforehand), then it works as intended: > > ACLOCAL_AMFLAGS = -I m4 > > However, if I use this syntax: > > ACLOCAL_AMFLAGS := -I m4 > > Then I get the following warning: > > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. This may be a slight bug in libtoolize, which is not part of Automake. I have added the libtool list to Cc. If libtoolize is still properly copying its macros into your m4 directory then I would ignore the warning. But two things to consider: (1) Automake is designed to produce makefiles which are portable in practice (i.e., run on a variety of make implementations). Use of := assignments fails on heirloom make, for example, and probably other implementations. (2) There is no functional difference between "=" and ":=" if the right hand side does not contain any variable references (as in your example). As an alternative, with recent versions of Automake you can try using AC_CONFIG_MACRO_DIRS in configure.ac rather than setting m4 directories in Makefile.am. I'm not sure if all the tooling has been updated to fully handle this new feature yet, though. [snip description of GNU make semantics] > That flavor is now a POSIX standard (with syntax "::="), so it should > be portable too (at least in the future). Well no, it doesn't follow that := assignments will become portable in the future just because POSIX standardized ::= syntax. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] any critical patches for a release this weekend?
On 2014-10-23 20:10 +0100, Gary V. Vaughan wrote:
> I plan to roll a release based off the v2.4.2 tag, incorporating fixes
> for version mismatches against Mac OS Yosemite this weekend - in
> consideration of the fact that there are still known regressions in
> master.
>
> If there's anything else I should include, or suggestions for a better
> revision to base the release from, please reply ASAP :-)
Would be nice to see da30ce4dc955 ("libtool: speed up ltwrapper_script
detection in execute mode")[1] in a release.
[1]
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=da30ce4dc9554c80f1931600af2b8bbab486476e
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: how to make libtool link with static system libraries instead of dynamic
On 2015-03-06 16:35 +, Andy Falanga (afalanga) wrote: > From: Peter Johansson [mailto:troj...@gmail.com] > Sent: Thursday, March 05, 2015 6:46 PM [...] > > On 03/06/2015 09:24 AM, Andy Falanga (afalanga) wrote: > > > I am wondering how I would make libtool link with static versions of > > already installed libraries instead of the dynamic ones. I have > > something like this in Makefile.am > > > > > > pyexec_LTLIBRARIES = mylib.la > > > mylib_la_LDFLAGS = -Wl,-Bstatic > > > mylib_la_LIBADD = -lz -lrt -lboost_python [...] > > The -all-static option might be useful for you > > Thanks for the suggestion but it didn't produce what I need. It had the > same effect as using "mylib_la_LDFLAGS = -static" which was to build only > static versions, or archives, of the python module. This makes it so that > the python interpreter cannot use the library: it must be shared. It is not generally possible to link static archives into shared libraries. The object files are usually incompatible. Nevertheless, you should be able to force the issue by directly listing archive filename(s) in _LIBADD, instead of using the -l option. Regards, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: GNU libtool-2.4.6 released [stable]
[Adding Automake] On 2015-03-23 16:00 +, Gary V. Vaughan wrote: > > On Mar 23, 2015, at 2:42 PM, Bob Friesenhahn > > wrote: > > > On Mon, 23 Mar 2015, Christian Rössel wrote: [...] > > > I discovered some files in > > > http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz that IMO > > > don't belong there. The filenames start with "._" (just do a 'find > > > . -name "._*"') and seem to contain dropbox meta data. [...] > > The 'file' command describes these as "AppleDouble encoded Macintosh file". > > > > It does not seem possible that these files were listed for inclusion > > in the release so they must be an artifact of the 'tar' program > > used. [...] > Most likely, Apple's tar is passing along file system metadata for the > destination machine :-( > > While I won't be rolling any future releases, it definitely seems > worth noting in the README-release notes that before uploading, to a) > use GNU tar b) check that there are no weird hidden files in the > tarball! Is this a bug in Automake then? Presumably it should either be generating good tarballs or failing hard. Maybe we could at least augment distcheck to test for these artifacts and reject the package in that case. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: How to stop these bounces
Hello, On 2015-03-25 14:20 +, Andy Falanga (afalanga) wrote: > I receive much of the mail from libtool in the form of "bounces". > Ordinarily, I wouldn't worry but this caused the daemon/management > process for autom...@gnu.org get irritated. I'm wondering, however, > why I'm having this type of trouble. The e-mail address I provided is > very much legit. Also, I'm signed up for the gcc list which delivers > all mail without the problem of bounces. Is there something I can do > to make the mailer daemon happy with this address? Problems with the mailing list itself should be sent to the list administrator: libtool-ow...@gnu.org Regards, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Running an uninstalled executable
On 2015-05-12 12:00 +0200, Alberto Luaces wrote: > David writes: > > El Tue, 12 May 2015 11:38:42 +0200 > > Alberto Luaces escribió: [...] > >> libtool --mode=execute program_binary > >> > >> but it fails, since there are undefined references to shared libraries > >> not installed in standard directories. > >> > >> Can libtool solve this problem for me? Yes, libtool can solve this problem! > > In order to use libraries not installed, but present in another > > directory (non standard), you have to use LD_LIBRARY_PATH > > > > http://stackoverflow.com/questions/695530/why-do-i-have-to-define-ld-library-path-with-an-export-every-time-i-run-my-appli > > > > Something like: LD_LIBRARY_PATH=/path/to/your/custom/library libtool > > --mode=execute program_binary [...] > Thanks, David. I was hoping that libtool set LD_LIBRARY_PATH for me. If the libraries you are linking against are libtool libraries (.la), and they are correctly installed, then libtool should be automatically setting the runtime path appropriately. That way, the libraries will be picked up automatically from the nonstandard location. Otherwise, you might consider linking your programs with the -R/path/to/your/libraries option. There should be no need to set LD_LIBRARY_PATH, although it can work in a pinch. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On 2/9/16, Vadim Zeitlin wrote: > I'd like to create Windows binaries for my software from Linux, which > includes creating a couple of DLLs and EXEs that use them. This is not too > difficult to do with just manual makefiles as both the cross-compiler and > linker work just fine. Libtool is another matter entirely however: > > 1. By default, libtool _silently_ doesn't create DLLs at all and >"win32-dll" LT_INIT() option needs to be used just to give it a chance >to fail. This default looks very unfortunate to me, static libraries >are almost never the right replacement for the DLLs and finding this >option when you don't know about it already is not obvious. I'd >strongly prefer if this option were enabled by default but failing that >libtool should at least give a noticeable warning if the target >platform is MSW and it is not enabled and require using no-win32-dll >explicitly to disable it. Here's the thing. Libtool is, by default, designed to transparently support the case where building a shared library is not possible. If you don't want to build static libraries, configure with --disable-static. Then you will get errors whenever building a shared library is not possible. If your package absolutely does not support static libraries at all, you can pass disable-static to LT_INIT (or controlled on a per-library basis with -shared). Nobody will be able to build your package where shared libraries are not possible. > 2. Enabling this option is not enough as you must also painstakingly add >-no-undefined to all LDFLAGS. Why does libtool need to force you to do >it instead of just using it unconditionally for all MSW DLLs knowing >that they can *never* have any undefined symbols? While using this >option is a good idea for the other platforms too anyhow, there just >doesn't seem to be any reason to not use it implicitly for MSW, is >there? Because unless you tell it, libtool has no way to know a priori whether a library will have undefined symbols or not. In order to transparently fall back to static libraries in this case libtool requires this information. In retrospect, the default (assume undefined symbols are possible) was probably a bad choice, because undefined symbols in libraries are rarely used. Thus, almost all libraries need to specify -no-undefined. But this can't be changed now without causing regressions. > 3. If you thought that making the two changes above would be enough to >finally create the DLLs instead of static libraries, as I did, you would >be wrong because if any of the DLLs link with any static libraries, it >will still create static libraries (albeit not silently this time) >because it fails to check if it can link link the DLL with these static >libraries. This is extremely frustrating because it has absolutely no >reason to be checking for anything at all, unlike some other platforms >(e.g. Linux x86-64), there are no restrictions whatsoever on the >libraries that the DLLs can be linked with as they don't need to contain >PIC code under MSW. After some digging around I could work around this >by doing "lt_cv_deplibs_check_method=pass_all" in configure before >LT_INIT() but this was far from obvious to find and, of course, not >guaranteed to work in the future. Why isn't "pass_all" the default (and >only possibility) for the MSW targets? The nasty warning when you link shared libraries against static libtool libraries is because this arrangement is not portable, and libtool is designed to facilitate portable packages. If you still want to do it anyway, the warnings can be avoided by passing libtool the .a file directly. Better to use shared libtool libraries (or libtool convenience libraries) if at all possible. > 4. After all the previous steps I could finally cajole libtool into >building the DLLs for my lib_LTLIBRARIES but it still silently builds >static libraries for all my noinst_LTLIBRARIES and I have no idea why. >I'm giving up for now because this is less critical, but it would still >need to be fixed if I want to continue using libtool instead of just >abandoning it (and, by necessity, automake) and going back to hand >written makefiles. These libraries are libtool convenience libraries. They are a bit different from normal libraries, as they cannot be installed (they are little more than a way to avoid passing a whole bunch of object filenames to libtool when linking). [snip] > If libtool has a goal of providing decent support for MSW DLLs, I > could try submitting patches changing the things above to work in a > more user-friendly way, but I'd really like to know if they would be > welcome first or if, perhaps, the way things [don't] work now is a > subtle hint that libtool just shouldn't be used if first-tier MSW > support is required. TBH I'm not sure what problem you are actually having. But I imagine patches to
Re: Re[2]: MSW DLLs support in libtool
On 2/9/16, Vadim Zeitlin wrote: > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler wrote: > NB> Here's the thing. Libtool is, by default, designed to transparently > NB> support the case where building a shared library is not possible. > > This is, IMO, an obsolete principle to follow. I admit it made sense in > the 90s when I first started using libtool and some proprietary Unix > systems didn't have support for shared libraries or, at least, didn't have > support for them in libtool. There are still systems where shared library support is limited or not available at all. The most obvious is DOS, which still sees some use. Next is Microsoft Windows (including Cygwin), where building shared libraries is not always possible (for example, if the library contains undefined symbols). Libtool will transparently handles this, by not building shared libraries when it cannot do so. The idea is that packages can still be useful without shared library support. In my experience, this works very well. The -no-undefined option is a signal to libtool: "This library is compatible with systems that don't support undefined symbols in shared libraries". It affects libtool's decision on whether or not a shared library is possible. Cheers, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On 2/10/16, Bob Friesenhahn wrote: > On Wed, 10 Feb 2016, Peter Rosin wrote: >> I agree wholeheartedly with the notion that --disable-static should end >> up in a failure and not somehow degrade to a static build anyway. I > > Is this not the case? I have seen builds on Windows fail due to using > --disable-static. I just tested it on a library which does not specify -no-undefined, and therefore won't be built as a shared lib on Windows: ./configure [...] libtool: warning: undefined symbols not allowed in i486-pc-mingw32 shared libraries; building static only ./configure --disable-static [...] libtool: error: can't build i486-pc-mingw32 shared library unless -no-undefined is specified So things fail as expected, although the error message seems a bit poor. Cheers, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On 2/10/16, Peter Rosin wrote: > Personally, I don't get why the win32 option exist at all. I see no > reason to discriminate against Windows like that. Make the no-windows- > purists opt out with no-win32 (or whatever) instead. What does the win32-dll option actually do? I just learned about it now... Using mingw32 it appears to not be necessary. Is it really just about saying whether the __declspec annotations are used or not, similar in spirit to -no-undefined (but package wide)? I get that the mingw32 has an "auto-import" feature so the annotations are not generally needed, so maybe this is why it works anyway. Regards, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Re[4]: MSW DLLs support in libtool
On 2/10/16, Vadim Zeitlin wrote:
> On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler wrote:
> NB> On 2/9/16, Vadim Zeitlin wrote:
> NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler
> NB> > wrote:
> NB> > NB> Here's the thing. Libtool is, by default, designed to
> NB> > NB> transparently support the case where building a shared library
> NB> > NB> is not possible.
> NB> >
> NB> > This is, IMO, an obsolete principle to follow. I admit it made
> NB> > sense in the 90s when I first started using libtool and some
> NB> > proprietary Unix systems didn't have support for shared
> NB> > libraries or, at least, didn't have support for them in
> NB> > libtool.
> NB>
> NB> There are still systems where shared library support is limited or
> NB> available at all. The most obvious is DOS, which still sees some
> NB> use.
>
> We can disagree about this, but I just don't think it's reasonable to
> create static libraries instead of DLLs under MSW out of concern for
> DOS.
The default (on all platforms) is to create both static libraries and,
when possible, shared libraries.
> NB> Next is Microsoft Windows (including Cygwin), where building shared
> NB> libraries is not always possible (for example, if the library contains
> NB> undefined symbols).
>
> The request to build a DLL with undefined symbols should result in an
> error, not "successfully" building a static library.
If you explicitly request a shared library (i.e., call libtool in
link mode with the -shared option), and it is not possible, you should
receive an error. If this is not happening, then this is probably a
bug in libtool.
> Again, I can understand that there can be some doubt about the default
> behaviour here and some people may believe that it's better to build
> anything at all rather than failing. I completely disagree with this
> because IMNSHO a low level tool such as libtool should do what it's
> told ("create a shared library") instead of what it thinks would be
> best. But it seems completely obvious to me that creating static
> libraries when disable-static is used is nothing more than a bug.
If libtool is creating static libraries by default when configured with
--disable-static, then that certainly seems like a libtool bug. I just
tested it, and the option works as expected for me. Can you provide
a test case?
Note that it is still possible to explicitly request static libraries:
the -static option to libtool will supersede the configure option (as
documented).
Cheers,
Nick
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Re[2]: MSW DLLs support in libtool
On 2/10/16, Vadim Zeitlin wrote: > On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler wrote: > NB> On 2/10/16, Bob Friesenhahn wrote: > NB> > On Wed, 10 Feb 2016, Peter Rosin wrote: > NB> >> I agree wholeheartedly with the notion that --disable-static > NB> >> should end up in a failure and not somehow degrade to a static > NB> >> build anyway. > NB> > > NB> > Is this not the case? I have seen builds on Windows fail due to > NB> > using --disable-static. > NB> > NB> I just tested it on a library which does not specify -no-undefined, > NB> and therefore won't be built as a shared lib on Windows: > > This just doesn't correspond to my experience: when cross compiling from > Linux using libtool 2.4.2, a static library is created. I cannot reproduce it. The build fails as expected. Can you reproduce with the latest release of libtool (2.4.6)? 2.4.2 is very old. Cheers, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On 2/11/16, Evgeny Grin wrote: > * change default shared lib mode from "on" to "auto" or "try" and fail > if shared lib cannot be created when mode is "on". With that logic > "make" will do what requested instead of guessing that "something may be > useful even if not requested". Alternatively - introduce new LT_INIT() > flag "no-fallback-to-static". This option already exists. It is called "disable-static". ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On 2/12/16, Evgeny Grin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 12.02.2016 0:14, Nick Bowler wrote: >> On 2/11/16, Evgeny Grin wrote: >>> * change default shared lib mode from "on" to "auto" or "try" and fail >>> if shared lib cannot be created when mode is "on". With that logic >>> "make" will do what requested instead of guessing that "something may be >>> useful even if not requested". Alternatively - introduce new LT_INIT() >>> flag "no-fallback-to-static". >> >> This option already exists. It is called "disable-static". > > Actually, no. See: Just to be sure: > $ libtool --version > libtool (GNU libtool) 2.4.6 > Written by Gordon Matzigkeit, 1996 Here you are running libtool installed on the system (by path lookup)... [...] > /bin/sh ../../libtool --tag=CC --mode=link gcc -fvisibility=hidden [...] ...here you are running a copy of libtool bundled with a package. They are not necessarily the same version. It would be better to provide a test case that others can run. Cheers, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Developing against $HOME/lib libraries and LD_LIBRARY_PATH
On 11/16/17, Paul "LeoNerd" Evans wrote: > I'm developing two different C libraries; lets just call them A and B. > A is fairly standalone, and B depends on A. [...] > But now suppose I have a possible change I want to make that needs > edits in both libraries. I don't want to build a new system package yet > and upset all the other users on this box. That's fine, I can just > install library A into my $HOME directory using > > $ make install PREFIX=$HOME > > In order to be able to test programs that use library A, I'm going to > need to set LD_LIBRARY_PATH now so they can find the library here in > preference to the system-installed one, so in my .profile I use If A and B are libtool libraries, and B is linked with libtool against the installed version of A in $HOME, and your programs are linked against B also using libtool, then this should all "just work". Libtool should be automatically inserting the necessary linker flags to use the version of A installed in $HOME (e.g., by setting DT_RUNPATH to $HOME/lib on ELF platforms)... > export LD_LIBRARY_PATH=$HOME/lib ... and there should be no need to do this, in part because hacks like this cause the type of problems you are seeing. If that is not happening then maybe the libraries and/or programs are being linked incorrectly, or perhaps there's a bug in libtool. Example: build+install libfoo to non-system location: % libtool --tag=CC --mode=compile gcc -c foo.c % libtool --tag=CC --mode=link gcc -rpath /tmp/instlib -o libfoo.la foo.lo % libtool --mode=install cp libfoo.la /tmp/instlib build libbar, linked against libfoo: % libtool --tag=CC --mode=compile gcc -c bar.c % libtool --tag=CC --mode=link gcc -rpath /usr/local/lib -o libbar.la \ bar.lo /tmp/instlib/libfoo.la build application linked against uninstalled libbar: % libtool --tag=CC --mode=compile gcc -c app.c % libtool --tag=CC --mode=link gcc -o app app.lo libbar.la Inspection of results: % ldd .libs/app [...] libbar.so.0 => not found libfoo.so.0 => /tmp/instlib/libfoo.so.0 (0x7fec8f7a9000) [we see that that the executable has the nonstandard location for libfoo, and libbar is not installed so it is not found by ldd, and finally...] % libtool --mode=execute ./app [works correctly] Cheers, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Developing against $HOME/lib libraries and LD_LIBRARY_PATH
On 12/1/17, Paul "LeoNerd" Evans wrote: > On Thu, 30 Nov 2017 15:38:20 +0100 > Thomas Jahns wrote: > >> The -rpath argument is for libtool (to tell it where the library will >> be installed). To tell libtool (or ld) where to search for libraries >> at run-time (if no .la files are installed) one needs to add -R or >> -Wl,-rpath options. > > So, should library A's .pc file include that in its output then? Is it > safe to do that unconditionally, even if the library is really just > installed in /usr/lib by the normal tooling? I wasn't sure if that was > safe to do. If library A is a libtool library then libtool should do the right thing automatically. All you should need to do is add the libtool library to your link command. If library A is not a libtool library then libtool won't necessarily know how to link it correctly, so it might need some help... It's hard to say more without knowing what libtool commands you are running and in what way they are not behaving as you expect. Cheers, Nick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 1/7/20, Martin Liška wrote: > nm -B detection fails to be detected with -flto and -fno-common CFLAGS: > > configure:6307: checking command to parse /usr/bin/nm -B output from gcc > object [...] > configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables > -fstack-clash-protection -Werror=return-type -g -fno-common -flto -O2 > -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables > -fasynchronous-unwind-tables -fstack-clash-protection > -Werror=return-type -g -fno-common -flto conftest.c conftstm.o >&5 > conftest.c:18:12: error: variable 'nm_test_var' redeclared as function > 18 | extern int nm_test_var(); >|^ > conftest.c:4:6: note: previously declared here > 4 |relocations are performed -- see ld's documentation on > pseudo-relocs. */ >| ^ > lto1: fatal error: errors during merging of translation units > compilation terminated. > > As seen, I bet problem is in conftstm.o file (for which I can't see > how it's created). Probably the file is missing declaration of > nm_test_var and so that it's implicitly deduced to be int > nm_test_var(). nm_test_var is defined as: char nm_test_var; The test works by running nm on this file, parsing the output, and then generating a C file which inserts references to all the exported symbols it finds. Then this is linked with the original file. With a "normal" compiler and -fno-common nm_test_var goes in BSS and will be marked "B" in the nm output. However, LTO breaks nm really badly and with -fno-common this variable gets marked as "T" in the nm output. So it is indistinguishable from functions and when the C file is generated, a function declaration for nm_test_var is emitted (if it was correctly marked "B", then a variable declaration will be emitted). It's really unfortunate that LTO breaks nm in this way. But even if this configure test didn't fail I suspect subsequent users of $global_symbol_pipe will expect nm to work properly and it won't. I'm not 100% sure which libtool features will be affected by this configuration failure. It doesn't fatally stop the configure script. Probably dlpreopen won't work at all? It's also unfortunate that since there is no way to directly reference symbol values in standard C, a common way to do so is with dummy array or function declarations, and lo and behold LTO apparently breaks this too... Cheers, Nick
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 1/7/20, Bob Friesenhahn wrote: > On Tue, 7 Jan 2020, Nick Bowler wrote: > >> On 1/7/20, Martin Liška wrote: >>> nm -B detection fails to be detected with -flto and -fno-common CFLAGS: > > I don't know what vintage this documentation is (the copyright says it > is from 2020 so it seems to be the latest), but the page at > https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html says this > about "-fcommon" > > "The default is -fno-common, which specifies..." > > GCC 9.2 documentation says that the default is target dependent, which > suggests that some targets use no-common by default. I think the fact that this test produces a common symbol most of the time, and that nm happens to work under LTO in this specific case, is mostly just a happy accident. >> I'm not 100% sure which libtool features will be affected by this >> configuration failure. It doesn't fatally stop the configure script. >> Probably dlpreopen won't work at all? > > Are there many users of dlpreopen()? I imagine there are users of -dlopen, which is supposed to automatically fall back to dlpreopen when shared library support is not available (for example, if the user configures the package with --disable-shared). Whether or not developers routinely test that their packages work with shared libraries disabled is another matter. Regardless, $global_symbol_pipe is part of the documented libtool interface, which says you can do: eval "$NM progname | $global_symbol_pipe" This is obviously busted because the failed configure test leads to global_symbol_pipe='' which will obviously cause problems in this usage (I just tested one of my scripts and yup, it is busted). But more importantly I suspect the actual busted feature is $global_symbol_to_cdecl, which is supposed to produce declarations for the symbols you get from global_symbol_pipe. This is clearly not working under LTO as it fails to distinguish functions and variables. It might be possible to detect this case in configure and come up with a symbol declaration that works for both functions and data, which might enable global_symbol_to_cdecl to generate working declarations, and would probably fix this configure test and typical usage scenarios like dlpreopen. >> It's also unfortunate that since there is no way to directly reference >> symbol values in standard C, a common way to do so is with dummy array >> or function declarations, and lo and behold LTO apparently breaks this >> too... > > LTO often causes strange issues. It needs to be used with care. > > Thus far I have seen LTO reduce the output executable size (sometimes > substantially if there is a lot of "dead" code) but I have not seen a > speed benefit to properly written code. When I last played around with LTO on my C code I was hoping to achieve reduced executable size but I found the results to be almost exactly the same as what I was already getting by compiling everything with -ffunction-sections -fdata-sections and then linking with -Wl,--gc-sections. And unlike LTO, those options don't break nm which would have required a massive amount of futzing with the build system to get things to even work. Cheers, Nick
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 2020-01-07, Nick Bowler wrote: >>> I'm not 100% sure which libtool features will be affected by this >>> configuration failure. It doesn't fatally stop the configure script. >>> Probably dlpreopen won't work at all? >> >> Are there many users of dlpreopen()? > > I imagine there are users of -dlopen, which is supposed to automatically > fall back to dlpreopen when shared library support is not available (for > example, if the user configures the package with --disable-shared). I tested that the -export-symbols-regex function is also busted by the failed global_symbol_pipe detection and that is probably a much more commonly used libtool feature. Cheers, Nick
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 2020-01-07, Nick Bowler wrote: > On 1/7/20, Martin Liška wrote: >> nm -B detection fails to be detected with -flto and -fno-common CFLAGS: >> >> configure:6307: checking command to parse /usr/bin/nm -B output from gcc >> object > [...] >> configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 >> -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables >> -fstack-clash-protection -Werror=return-type -g -fno-common -flto -O2 >> -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables >> -fasynchronous-unwind-tables -fstack-clash-protection >> -Werror=return-type -g -fno-common -flto conftest.c conftstm.o >&5 >> conftest.c:18:12: error: variable 'nm_test_var' redeclared as function >> 18 | extern int nm_test_var(); >>|^ >> conftest.c:4:6: note: previously declared here >> 4 |relocations are performed -- see ld's documentation on >> pseudo-relocs. */ >>| ^ >> lto1: fatal error: errors during merging of translation units >> compilation terminated. [...] > However, LTO breaks nm really badly and with -fno-common this variable > gets marked as "T" in the nm output. So it is indistinguishable from > functions and when the C file is generated, a function declaration for > nm_test_var is emitted (if it was correctly marked "B", then a variable > declaration will be emitted). Workaround: add -ffat-lto-objects to CFLAGS so you get proper symbol tables in object files and then set NM='nm --plugin ""' to completely disable the busted LTO support in nm. For example: ./configure CFLAGS='-flto -fno-common -ffat-lto-objects' NM='nm --plugin ""'
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
On 2020-01-08, Martin Liška wrote: > On 1/7/20 10:40 PM, Nick Bowler wrote: >> Regardless, $global_symbol_pipe is part of the documented libtool >> interface, which says you can do: >> >>eval "$NM progname | $global_symbol_pipe" >> >> This is obviously busted because the failed configure test leads to >> global_symbol_pipe='' which will obviously cause problems in this >> usage (I just tested one of my scripts and yup, it is busted). > > Yes, that's what I see for many package failures in openSUSE when I enable > -fno-common in optimization flags: Interestingly, I noticed that the dlpreopen support bits seems to actually have code to handle the case where global_symbol_pipe is empty (and appears to make an effort to display a big fat warning message that the feature is unlikely to work, but allows the user to proceed anyway). However the -export-symbol-regex implementation uses global_symbol_pipe without any check so if global_symbol_pipe is empty then you get shell syntax errors when using this feature. In principle a big fat warning message would be OK for this feature as well, falling back to a no-op. The libtool documentation does not seem to mention an empty global_symbol_pipe as a possibility so I expect any users of this feature will not check this (this was the case with my script). The libtool configure test could be improved so that the test for global_symbol_pipe does not depend on global_symbol_to_cdecl working. Cheers, Nick
Re: Q: library dependencies
On 2020-09-24, Oleg Smolsky wrote: > Hello, I'm working on an autotools-based build system and finally decided to > look into these messages: > > CXXLDlibtop.la > copying selected object files to avoid basename conflicts... > > It looks like libtool links (copies?) .o files when it finds a dupe in the > dependency DAG. Here is the situation I have w.r.t. the dependencies: > > libtop.la: liba.la, libx.la > liba.la: libb.la libc.la libx.la > > All these libraries are static, noinst_LILIBRARIES and the dependencies are > expressed via _LIBADD syntax: > > libtop_la_LIBADD = liba.la libx.la > > I do this to get transitive dependencies where the top-level executable just > needs to link to link libtop.la. > > I think the issue is with libx.la as it is present in two different branches > of the dependency DAG. This kind of thing is common in large projects and > seems strange that libtool is trying to be smart about it. > > Is there a way to tell automake/libtool to disable this copying and just do > straightforward linking? I wonder if the current behavior results in > unnecessary bloat?.. Or perhaps I am saved by the linker that would dedup? Unless I misunderstand something, what you describe is the documented and expected behaviour. When using primaries such as noinst_LTLIBRARIES, Automake will generate rules that create libtool convenience libraries. Such libraries are basically intended to be a convenient shorthand for directly listing the libtool objects that make up the convenience library whenever you use libtool to link with it. So when you create another libtool convenience library, liba.la, linking with libx.la, since libx.la is a shorthand for directly listing all its objects this creates a new library that contains all the objects that made up libx.la. Now when creating the libtop.la convenience library, you link against _both_ convenience libraries liba.la and libx.la. This directly includes all the objects of liba.la and all the objects of libx.la. But as the objects of libx.la are duplicated in liba.la, this means some objects are to be included twice into libtop.la. Libtool has to rename one of the objects to make this work (hence the "copying ... to avoid basename conflicts"). I assume this is not the desired result. Probably simplest to just arrange for libx.la to either be a dependency of libtop.la OR liba.la, but not both. Cheers, Nick
Re: [EXTERNAL] Re: Q: library dependencies
On 2020-09-25, Oleg Smolsky wrote: > On Fri, Sep 25, 2020 at 6:58 AM Bob Friesenhahn > wrote: > > Libtool convenience libraries are not "real" static libraries. > > Instead they are object files stored in an archive file. Prior to > > use (when linking using libtool) the objects are extracted and > > passed to the linker directly (perhaps with renaming to assure > > there are no over-writes during the extraction). > > Well, AFAIK any well-formed .a file (an archive) is a static lib. And these > can be passed to the linker. Are you saying that libtool extracts the > individual .o files instead passing -lfoo (for libfoo.a)? Yes, this is how libtool _convenience_ libraries work (at least conceptually: I think in some cases libtool is able to use linker options like -Wl,--whole-archive, if supported, to achieve equivalent results without literally unpacking the archive). This is because _convenience_ libraries are a shorthand for linking the individual libtool objects that comprise the library. Linking an archive is very different from linking the individual objects that make up the archive. Regular (installed) libtool libraries work differently (they are linked like normal libraries). [...] > > The convenience library does not do anything regarding mutiply-defined > > symbols (at the C language level) while linking. If there is a > > conflict then the linker should normally fail. > > I find the situation puzzling. My project has just over a hundred of these > LT convenience libraries and there are several places where collisions > result in renaming. Yet nowhere do I see multiply defined symbols. I tested it a bit and it seems that when a convenience library is linked into a _program_, libtool will just pass the static .a file directly to the linker, without unpacking, using whole archive mode or doing anything particularly special. I guess this is fine because presumably portable programs cannot tell the difference. Because of this behaviour, duplicate objects in convenience libraries may not be a significant problem in practice for linking programs. With normal linkers, individual object files that resolve undefined symbols are effectively picked out of the archive one at a time until there are no remaining undefined symbols that could be resolved by the library. So once one of the duplicate objects is picked, the other is essentially removed from consideration since it does not provide different symbols. I'm not sure if there are any historical exceptions to this linker behaviour that would affect portability of a package depending on this. You will almost certainly get multiple definition errors if you tried to link such a convenience library into a shared libtool library. Cheers, Nick
Re: [EXTERNAL] Re: Q: library dependencies
On 2020-09-25, John Calcote wrote: > On Fri, Sep 25, 2020 at 10:45 AM Bob Friesenhahn > wrote: >> Exactly! It might as well be a tar file except that the 'ar' archiver >> knows how to add/update/remove files from it and that is not possible >> with a tar file. The ability to do incremental updates of the archive >> file is important as objects are built/rebuilt. The 'make' program >> itself already understands archive files. >> > > I did not know this about libtool and convenience libraries. Do you have > any historical notion of why this was done? I ask because this sort of > behaviour total defeats the linker's ability to discard unused objects, > does it not? As I mentioned elsethread, at least with current versions, this only appears to actually happen when convenience libraries are linked into libraries (which OP is doing). This _has_ to happen for the use case that convenience libraries are described to be, well, convenient for: linking a set of common object files into multiple shared libraries. Obviously "unused object" is a nontrivial concept when linking libraries. Cheers, Nick
Re: [EXTERNAL] Re: Q: library dependencies
On 2020-09-25, Howard Chu wrote: > Bob Friesenhahn wrote: > > ... static libraries do not technically have "dependencies" since they > > only represent a compilation step (no linking). If a static > > library may also be built as a shared library then it may have > > dependencies and should be described as such. > > I've always found this distinction ridiculously annoying. A > program/project that links perfectly fine when its explicitly listed > dependencies are shared libraries suddenly fails to link when you > change to using -static. It's also simple to remedy - just list the > dependencies inside a member of the archive file. Libtool already implements a portable mechanism for ordinary (installed) static libtool libraries to depend on other libraries, since libtool libraries carry dependency information which is installed alongside the static archive file. This is also necessary on some platforms with shared libraries. Of course, only packages that use libtool for linking can benefit from the dependency information in libtool libraries. > Please consider this thread and adopting the feature implemented there: > https://sourceware.org/pipermail/binutils/2020-September/113188.html It's unclear to me what, if anything, needs to be done for libtool to "adopt" this feature? Cheers, Nick
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On 2021-08-10, Vincent Torri wrote: [...] > As I have said, the problem is not the lib itself. There is no problem > with the lib. The problem is with the binary : when I compile it, > there is no way to know if the library, that the binary uses, is a > static library or shared library (know == having a macro to > distinguish shared lib and static lib) I'm not too familiar with shared libraries on Windows, but I think mingw solves this particular problem by generating static wrapper libs with stub functions that then call the real implementation in the dll. With such a wrapper, I suppose there is no difference (from the program's perspective) between linking against the real static archive versus linking against the wrapper. When using mingw and libtool simple libraries appear to "just work" at least. Without such a wrapper I suppose you will need to know at compile time which libraries will be used in the future at link time. I don't think libtool can make any assumptions here in general, as link options are not typically passed to compile mode commands (and in fact, many libtool options are overloaded to mean different things depending on whether you are running it in compile or link mode). It all seems very annoying indeed. I wonder how Windows users deal with this. Cheers, Nick
Re: Problem with build
Hi, On 2022-08-01, aotto wrote: > but in ONE library I dont want to have a static library build because it > is only used as dlopen (by tcl)… [...] > pkglib_LTLIBRARIES = libtclmkkernel.la [...] > question what I have to-do to avoid a "static" library "libtclmkkernel.a" Since this seems to be a libtool question, I have added the libtool list to Cc. The following compilation option[1] seems appropriate: -shared Even if Libtool was configured with --enable-static, the object file Libtool builds will not be suitable for static linking. Libtool will signal an error if it was configured with --disable-shared, or if the host does not support shared libraries. And the following link option[2]: -shared If output-file is a program, then link it against any uninstalled shared libtool libraries (this is the default behavior). If output- file is a library, then only create a shared library. In the later case, libtool will signal an error if it was configured with --disable-shared, or if the host does not support shared libraries. So, if you add -shared to libtclmkkernel_la_CFLAGS and also to libtclmkkernel_la_LDFLAGS, I'd expect this to work as you expect (I've not tried it). [1] https://www.gnu.org/software/libtool/manual/libtool.html#Compile-mode [2] https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode Hope that helps, Nick
Re: lt_dlforeach replacement?
On 2022-08-03, Zopolis0 wrote:
> it looks like the intended replacement [for lt_dlforeach] is
> lt_dlhandle_map. That requires a lt_dlinterface_id variable, though.
Just reading the docs, I think the way it is supposed to work is you
first register an interface with a null matching callback, for example:
lt_dlinterface_id everything = lt_dlinterface_register("everything", NULL);
Then hang onto this ID to use with lt_dlhandle_map in order to iterate
over all loaded modules like lt_dlforeach used to do.
Cheers,
Nick
Re: [sr #110796] libtool-2.4.7/build-aux/git-version-gen uses kind of a hack
On 2022-12-07, anonymous wrote: [...] > On an elderly Mac with PPC Mac OS X 10.4.11, Tiger, this was reported: > > expr: brackets ([ ]) not balanced > > It comes from this line > >76 year=`expr "$scriptversion" : '\([^-]*\)'` > > On two more up-to-date intel Macs expr worked correctly. I can make another > test on PPC Mac OS X 10.5.8, Leopard. FWIW this specific problem with Mac OS expr, as well as a possible workaround, is discussed in the portable shell programming section of the Autoconf manual[1]: On Mac OS X 10.4, expr mishandles the pattern ‘[^-]’ in some cases. For example, the command expr Xpowerpc-apple-darwin8.1.0 : 'X[^-]*-[^-]*-\(.*\)' outputs ‘apple-darwin8.1.0’ rather than the correct ‘darwin8.1.0’. This particular case can be worked around by substituting ‘[^--]’ for ‘[^-]’. [1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-expr-1 Cheers, Nick
Re: libtool (use with autotest)
On 2023-07-24, Simon Sobisch wrote:
>
> I hope to possibly get an answer by moving this question to the
> appropriate lists :-)
> For more context I provide the original responses to this topic.
>
> Am 06.07.2023 um 14:55 schrieb Jose E. Marchesi:
>>
>>> On 2023-07-03 17:16:59 +0200, Bruno Haible wrote:
Someone wrote:
> Without relinking at install time, I don't see how tests can
> reliably load the just-built library from the sources (objdir
> really) rather than loading the installed library. Unless
> perhaps there is a belief that LD_LIBARY_PATH is reliable and
> supercedes, and there are wrappers
Yes, on all ELF systems, libtool creates wrappers that set
LD_LIBRARY_PATH, for all programs that link to shared libraries in
the build dir.
>>>
>>> But wrappers have drawbacks: they make the use of gdb or valgrind
>>> less convenient.
>>
>> Just a tiny bit less convenient:
>>
>> $ libtool --mode=execute gdb ./prog
>> $ libtool --mode=execute valgrind ./prog
>
> Just to recheck:
>
> When using both autotest (autoconf) generated testsuites and libtool,
> then how should we handle the following, given that we generate
>
> bin/runner
> bin2/compiler
> runtime/librun
>
> * specify binaries to test AT_TESTED
> They are not in PATH, so should we add the libtool generated binaries'
> path to PATH for `make check` before the testsuite is executed?
The normal way is to set AUTOTEST_PATH so that all the programs under
test are in it. When using Autoconf, this is usually done via the
the second argument to the AC_CONFIG_TESTDIR macro.
I must be missing some context here, as I'm afraid I don't understand
what the problem is. To use valgrind in an Autotest test suite together
with libtool, I would do something like this (untested):
m4_divert_text([PREPARE_TESTS], [: ${LIBTOOL="$SHELL $builddir/libtool"}
])
AT_TESTED([my_program])
AT_SETUP([my test w/ valgrind])
AT_CHECK([$LIBTOOL --mode=execute valgrind my_program], [...])
[...]
AT_CLEANUP
> Bonus:
> How to do this in a way that allows `make installcheck`?
If you use AUTOTEST_PATH to locate the programs under test, I wouldn't
expect there to be any particular problem with installcheck.
Hope that helps,
Nick
Re: stable release from 2.4.7 branch?
On 2023-10-22 10:48, Shterenlikht, Anton wrote: > I'm working on > > https://savannah.gnu.org/support/index.php?110947 > > and tried the development version from git. > > That version identifies itself as > > $ libtool --version > libtool (GNU libtool) 2.4.7.4-1ec8f > > yet the latest stable version is 2.4.6. > > Does this mean there are still no stable > versions in the 2.4.7.* branch? Libtool 2.4.7 was released[1] back in March of last year. The source archives for this version are available on the GNU FTP site[2]. However, it appears the web site[3] was never updated accordingly. [1] http://lists.gnu.org/archive/html/info-gnu/2022-03/msg6.html [2] http://ftp.gnu.org/pub/gnu/libtool/ [3] http://www.gnu.org/s/libtool Cheers, Nick
Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo
On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get fixed.) At least, I have no idea what to do about, or even work around, that error :(. This could still be (partially) an Automake issue, since the problem appears partially related to how Automake is calling libtool from the build rules (it is missing the --tag option), and I think those are coming from Automake. However it looks like there is no tag defined for Objective C[1] (presumably it would be --tag=OBJC). Adding this option does appear to make things "work" in the sense that libtool just complains about the unknown tag but then proceeds to actually do stuff, rather than exiting outright with a fatal error. Interestingly the libtool manual also says "If [libtool] can't infer a tag, then it defaults to the configuration for the C language", which is clearly not the case (it seems what actually happens is that if libtool can't infer a tag then it exits with a fatal error). So I wonder if this is actually a regression in libtool. [1] https://www.gnu.org/software/libtool/manual/libtool.html#Tags Cheers, Nick
Re: How to force libtool to use CXX mode?
On 2024-05-14 17:02, Bob Friesenhahn wrote: > Since it is not allowed to wrap a target replacement in an Automake > condition, I am finding it necessary to write new rules which use > variables that I define. I think it works despite the strange warning about multiple targets? But regardless, you can use conditionals around commands in a target, instead of the target itself, so you could presumably avoid the problem overriding rules that way, e.g.: foo$(EXEEXT): if MY_CONDITION do stuff else do different stuff endif Then you only get the warning about overriding a builtin rule. No idea how much that helps with your problem though. Cheers, Nick
Re: Issue with added '-threads' added while using Intel 2024.0.0 C compiler icx
On 2024-08-23 13:35, Witold Interewicz wrote: > I have 2 Qs here: > - What is (in short/sketch) the set of conditions that causes libtool > to add this switch '-threads' (or where may I read about it)? It could be coming from another library you are using. For example, some libtool library (.la file) might contain a line like inherited_linker_flags='-threads' which will cause libtool to add the flag when you use that library with libtool. Perhaps some library was built using a different compiler which uses different options and these got embedded into the installed library. > - Should I look for solution of this problem here in libtool GNUs' > world or in the Intel's world? It's probably just a matter of identifying the problematic library and then correcting it on your system. > PS. Please let me know if it is ill posed problem at all or if you > don't discuss issues involving non-GNU compilers at all. Libtool should work with non-GNU compilers. Hope that helps, Nick
Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12
On 13:19 Fri 30 Oct , Philip A. Prindeville wrote: > The problem is that this is an early linkage on the build host, where > the eventual DESTDIR hasn't yet been specified, but the resultant > libusbpp.la ends up looking like: I suspect that you have two libtool libraries in the same source tree, with one linked against the other. Chances are, the compiled binaries in the .libs directory are perfectly fine, and libtool is destroying them when you run 'make DESTDIR=/path/to/staging/dir install'. So we have libfoo.la and libbar.la, libbar links with libfoo and. Furthermore, you have a version of libfoo already installed on the host system, in /usr/lib. You cross-compile the package, using --prefix=/usr/lib (since that is where it will finally end up). Then you do 'make DESTDIR=/path/to/staging/dir install', and libtool decides to re-link the libraries against the libraries in the final installed location. In this case, it is /usr/lib. The problem is that the libfoo in /usr/lib is the wrong one, since the cross-compiled libfoo never got installed there! The workaround here is to manually copy the libraries from .libs into your staging directory. IMHO the fix is to make libtool not re-link anything if DESTDIR is set -- correct me if I'm wrong, but it seems to me that the current behaviour cannot possibly be correct on any platform, even on the ones that require re-linking. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Issue with libtool when cross-compiling
On 16:34 Fri 12 Feb , Thomas Petazzoni wrote: > Hello, > > I'm a contributor to the Buildroot project (http://www.buildroot.org), > a build system for embedded Linux systems. We integrate many packages > in order to ease their cross-compilation. > > I'm facing an issue with several packages where libtool wants to link > against libraries of the host (in /usr/lib), and I don't know what > is happening. It is very likely a problem in the environment variables > or the options we pass to the configure script, but I'm unable to find > where the problem is, and thought that libtool experts might have an > idea on what's going on. This happens when doing a DESTDIR install when libtool libraries link against other libtool libraries in the same package. The compiled libraries are completely correct, but 'make install' destroys them. Unfortunately, the only solution that I'm aware of is to avoid using 'make install' and to copy the files from .libs manually :( -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool on AIX - soname feature inconsistent?
On 2024-11-27 01:01, Ben Huntsman wrote:
> In particular, I noticed that if you add libtool to a project by
> calling LT_INIT, and then run ./configure with the
> --with-aix-soname=svr4, the .la files that get produced with the
> library_names='whatever.so.3 whatever.so', but if you call
> LT_INIT([aix-soname=svr4]) and then don't specify --with-aix-soname to
> ./configure, the .la files have library_names='whatever.a whatever.a"
>
> It seems to me that --with-aix-soname=svr4 and
> LT_INIT([aix-soname=svr4]) should be identical, correct? Is this a
> libtool bug, or is this a bug in the particular project leveraging
> libtool? (OpenAFS, in this case).
Yes this looks like a libtool bug to me.
I notice that when aix-soname=svr4 is NOT passed to LT_INIT, if you look
in the generated configure script, you can find the following code in
the following order
### FIRST PART
if test "${enable_shared+set} = set; then
[...]
else
enable_shared=yes
fi
[...]
### SECOND PART
case $host,$enable_shared in
power*-*-aix[5-9]*,yes)
*)
esac
And in this case, when you run configure --with-aix-soname=svr4, you can
see the output line:
checking which variant of shared library versioning to provide... svr4
But when I use LT_INIT([aix-soname=svr4]), for some reason the order of
these two parts in the configure script are reversed. As a result, the
default value of enable_shared is not set before it is used, and the
output about shared library versioning is conspicuously missing. This
probably causes the other strange behaviour as some variables are not
being set properly.
If you explicitly run ./configure --enable-shared it goes back to normal
(with svr4 versioning as expected), as this has the effect of setting
enable_shared=yes early.
Cheers,
Nick
