Re: How to force libtool to use CXX mode?
On 5/13/24 20:52, Bruno Haible wrote: Bob Friesenhahn wrote: Automake does have a critical bug in that for a target which only optionally has C++ sources, that target is always linked using C++. Without this issue, the trick of including an empty optional C++ source file in the build would work. But I do not want GraphicsMagick to require a C++ compiler. For a target 'foo', Automake uses a foo_LINK variable, for which it provides a default definition. Since you are not satisfied with this default definition, you can and should provide your own definition of this variable. You can then decide yourself whether it uses --tag=CC or --tag=CXX and $(CCLD) $(AM_CFLAGS) $(CFLAGS) or $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS). See e.g. in gettext/gettext-tools/src/Makefile.am the 'msgmerge' target and the msgmerge_LINK variable. This definition has been in use for ca. 20 years. The GraphicsMagick Makefile.in file has 107 such link statements for libraries/modules and 112 foo_LINK variables overall. Unfortunately, Automake is not consistent and there is a entirely different link request used for optionally built programs such as for tests. Indeed I am most recently proceeding down this path. 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. The goal is to support linking as C or C++. Not all of the libraries, modules, or programs need to be linkable with C++ but this seems like quite a lot of messy work and quite a lot of divergence from the original Automake Makefile. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: How to force libtool to use CXX mode?
On 5/13/24 16:37, Karl Berry wrote: convince Automake to force libtool to link using the C++ compiler When there are no C++ sources? Why? Just trying to understand ... There are no C++ sources from my project, but there is a C++ compiler used for the overall build. As clarification, this is for oss-fuzz's clang ubsan build, which is an almost completely static build so there are no shared libraries to provide their dependencies by default. When clang++ is enabled for ubsan, it adds additional dependency libraries (presumably -lubsan). The theory is that if linking is done using the same compiler then the dependency libraries brought in due the compiler mode will be applied automatically. I'm sorry Bob, but I just don't know. Maybe the just-released libtool-2.5.0 alpha offers some new help? I don't think so. If there is some bug in or feature for Automake that would help, I'm open to suggestions (and patches). It kind of sounds like more on the libtool side? --sorry, karl. Automake does have a critical bug in that for a target which only optionally has C++ sources, that target is always linked using C++. Without this issue, the trick of including an empty optional C++ source file in the build would work. But I do not want GraphicsMagick to require a C++ compiler. I have been working to supply replacement's to Automake's target definitions, but it is very messy and not future safe. Without support for this in Automake, I feel that there is too much effort, and future risk. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
How to force libtool to use CXX mode?
I have expended quite a few days already (over a 6 month span) with attempting to convince Automake to force libtool to link using the C++ compiler. I tried optionally adding an empty C++ source file to the target build but this does not work because then Automake always assumes C++ linkage, even if no C++ source files were included. I previously encountered a libtool-related bug where it determines that the C compiler needs -lm, but the C++ compiler does not, stripping the -lm and resulting in a failed link. Today I read this Automake manual page: https://www.gnu.org/software/automake/manual/html_node/Libtool-Flags.html and so I used the program_LIBTOOLFLAGS or library_LIBTOOLFLAGS to add --tag=CXX to the options. I thought that this must be working. I found that it is not working as desired. I end up with this bad case for compiling C code (did not want to have the --tag=CXX!) /bin/bash ./libtool --tag=CC --tag=CXX --mode=compile clang ... and this command to link the C code using the C++ compiler (should be clang++!) /bin/bash ./libtool --tag=CC --tag=CXX --mode=link clang Libtool misreports the tag it is using so it reports CCLD when the tag is presumably overridden by CXX. The end result fails. Is there a way to solve this problem beyond replicating many modified Makefile.in hunks into Makefile.am? I am faced with backing out my attempt for yet another time. :-( Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: .la file dependency_libs dropping sole -lm dependency
Well this definitely looks like a bug. I can't imagine any reason that would be correct. I'm trying to reproduce it now, with GraphicsMagick. I filed a bug [1]. Thanks for the detailed report! Thank you very much for volunteering to be a libtool maintainer. You would need latest GraphicsMagick code from Mercurial in order to reproduce. And then configure with something like: configure 'CC=gcc-10' 'CXX=g++-10' 'CFLAGS=-O2 -g -Wall -Winline -W -Wformat-security -Wpointer-arith -Wdisabled-optimization -Wmissing-noreturn -Wno-unknown-pragmas -Wunused-but-set-variable' 'CXXFLAGS=-O -g -Wall -Winline -W -Wextra -Wno-unknown-pragmas' 'LDFLAGS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib' '--enable-maintainer-mode' '--disable-silent-rules' '--with-quantum-depth=16' '--disable-shared' '--enable-static' '--disable-openmp' '--without-threads' '--without-bzlib' '--without-dps' '--without-fpx' '--without-gs' '--without-jbig' '--without-webp' '--without-heif' '--without-jpeg' '--without-jp2' '--without-jxl' '--without-lcms2' '--without-lzma' '--without-png' '--without-tiff' '--without-trio' '--without-ttf' '--without-wmf' '--without-xml' '--without-zlib' '--without-zstd' '--without-x' However, I now know what the problem is. Recently there is a desire to link using the C++ compiler because there are C++ libraries involved and it is said that it is most portable to link using the C++ compiler (so exceptions are assured to work, etc.). After adding --debug to the libtool flags, I can see that there is tremendous effort to reject libraries that the compiler adds by default. The testing is being done with the C++ compiler and it seems like -lm is added by default when using the C++ compiler. It also seems that -lm is not added by default when using the C compiler. The -lm library is omitted due to the C++ compiler, but the utilities/gm program (a tiny bit of C code) is still being linked using the C compiler. If I link it using the C++ compiler, then there is a successful link. If libtool is going to test based on the C++ compiler, then it should also assure that linkage of dependent programs is done using the C++ compiler. I now know how to solve this issue as pertains to GraphicsMagick. It seems that this disparity between C and C++ may cause harm for other software as well. The issue with -lm is well hidden because many libraries depend on -lm and if shared libraries depending on -lm are linked with, then a linkage dependency with -lm is implicitly added, hiding the underlying issue. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: .la file dependency_libs dropping sole -lm dependency
On Wed, 31 Jan 2024, Bob Friesenhahn wrote: bin/bash ./libtool --tag=CXX --mode=link g++-10 -no-undefined -export-symbols-regex ".*" -version-info 27:4:24 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -o magick/libGraphicsMagick.la -rpath /usr/local/lib [ list of .lo files ] -lm An I misunderstanding something, or is this a bug in libtool? What am I missing in order for this to work? As further information on this issue, I tried using '-lm -lm' and there was no change in the results: # Libraries that this one depends upon. dependency_libs=' -L/usr/local/lib' Then I tried using '-ljpeg -lm' and I see that the -ljpeg gets added, but not the -lm: # Libraries that this one depends upon. dependency_libs=' -L/usr/local/lib -ljpeg' and then I tried using '-lm -jpeg', and I see that there are again no dependency libraries at all: # Libraries that this one depends upon. dependency_libs=' -L/usr/local/lib' After testing various permutations, I see that anything starting with '-lm' gets removed in entirety. This same thing happens under Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
.la file dependency_libs dropping sole -lm dependency
I am encountering an issue when building a static build of GraphicsMagick in that although -lm is supplied to libtool while linking the static library, the associated .la file is missing -lm in dependency_libs. If several more libraries are specified (also including -lm) then they all seem to be included in dependency_libs. The linkage is using --tag=CXX because there are some modules compiled with C++. Programs which depend on the library fail to link due to missing the symbols from '-lm'. The libtool used reports itself as % /usr/local/bin/libtool --version libtool (GNU libtool) 2.4.7 Written by Gordon Matzigkeit, 1996 Copyright (C) 2014 Free Software Foundation, Inc. which I think is confusing since the tarball date is 2022-03-17 and the copyright at the top of libtool.m4 is up to 2022 although several lines down where the copyright message comes from, I see "Copyright (C) 2014 Free Software Foundation, Inc.". The OS used is Ubuntu 20.04 LTS. My expectation is that the .la file in the build tree will remember which compiler/language needs to be used for linking, and remember the library dependencies, so that dependent libraries and programs which depend on the library do not need to. In magick/libGraphicsMagick.la, I see: # Libraries that this one depends upon. dependency_libs=' -L/usr/local/lib' rather than this: # Libraries that this one depends upon. dependency_libs=' -L/usr/local/lib' -lm As a result, linking fails when programs which depend on this library attempt to link with it using libtool in the same build. The linking request looks somewhat like (abbreviated for clarity): bin/bash ./libtool --tag=CXX --mode=link g++-10 -no-undefined -export-symbols-regex ".*" -version-info 27:4:24 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -o magick/libGraphicsMagick.la -rpath /usr/local/lib [ list of .lo files ] -lm An I misunderstanding something, or is this a bug in libtool? What am I missing in order for this to work? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs
On Wed, 17 Jan 2024, Roumen Petrov wrote: Hi All Mike Frysinger wrote: On 16 Jan 2024 21:11, Brad Smith wrote: libtool: remove OpenBSD support for non-shared and a.out archs OpenBSD stopped supporting the last non-shared arch 8 years ago and stopped supporting a.out 10.5 years ago. This cannot be reason to drop support. For instance RHEL was release in 2011 and is still supported. This seems like a strong argument, but there are other factors. A strong reason to stop supporting a target/version is if it's existence interferes with maintenance/development and there is no reasonable means available to verify that the support still works. Support which is not periodically tested likely does not work any more. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [PATCH 0/3] Fix typos and update links
On Thu, 23 Nov 2023, Antonin Décimo wrote: As a side question: is libtool still maintained? I also note that the latest version isn't reported on the webpage (2.4.7 instead of 2.4.6). Which web page (e.g. URL, documentation file in libtool git) are you talking about? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [EXTERNAL] Re: Q: Forcing a -Wl,-rpath arg to static lib users
On Fri, 18 Nov 2022, Oleg Smolsky wrote: The libtool provided as part of a Linux distribution often hacks libtool so that it does not include full dependency information in the library.la files. They do this in order to avoid "excessive linkage" because they do not want the program/library to retain full linkage details in case the OS changes the libraries. Oh, that's a very interesting hint! thanks, Bob! I am using libtoon from the distro. What does it take to take libtool from upstream? Certainly I can fetch its source... but how do I marry that with the `autoreconf` invocation that drives build system generation? A reasonable thing to do would be to download the autoconf, automake, and libtool tarballs from https://ftp.gnu.org/gnu/. Build and install each one using the same installation prefix. It is best if the installation prefix does not interfere with your operating system (the default of "/usr/local" normally works). Relevant m4 files would appear in something like /usr/local/share/aclocal. It is possible that you might want to install some other autotools-related packages. If it is just some m4 files that you need, it may be sufficient to copy the needed file from your operating systems /usr/share/aclocal directory. Make sure that the bin directory for those tools is in your PATH before the OS-provided tools so the new software appears by default. Then do 'autoreconf --force' in your project directory to regenerate all of the autotool stuff. Maybe this will make a difference. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Q: Forcing a -Wl,-rpath arg to static lib users
On Wed, 16 Nov 2022, Oleg Smolsky wrote: Leaving it here for posterity. Perhaps someone will do this with a bit more finesse and turn it into a proper feature. Are you using libtool as originally distributed by the FSF or are you using a libtool provided by a Linux system package? The libtool provided as part of a Linux distribution often hacks libtool so that it does not include full dependency information in the library.la files. They do this in order to avoid "excessive linkage" because they do not want the program/library to retain full linkage details in case the OS changes the libraries. Shared libraries often/usually only need to know the libraries that they immediately link with, but static libraries need to know everything, and the library.la files are intended to fill that gap. I am thinking that you may be trying to fix something which should already be working with the original FSF libtool. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: rpath stripping
On Mon, 18 Apr 2022, Richard Purdie wrote: As I understand it the dynamic loader has a set of search paths it falls back to (sys_lib_dlsearch_path in libtool). An RPATH or RUNPATH entry matching a system loader path isn't usually of much use, it just takes up space. It is of use since it influences the search order. For example, if /usr/local/lib is in the system loader path, and the user installs a library in /usr/local/lib, then the user likely wants the library she has just installed to be used by apps which link with it, rather than some similar library in the default system loader path. Likewise, it is pointless to install a library which will never be used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [PATCH v2 04/12] ltmain.in: Don't encode RATHS which match default linker paths
On Sat, 16 Apr 2022, Sam James wrote:
From: Richard Purdie
We don't want to add RPATHS which match default linker search paths, they're
a waste of space. This patch filters libtools list of paths to encoode and
removes the ones we don't need.
While cross-compiling some software ("Curl") for a target which
already had an older install present, libtool ended up defeating me.
I wanted to produce my own libcurl and have the apps specifically
linking with it, use the libcurl that I had built. I wanted to leave
the libcurl that came with the system in place for the many other
existing apps which needed it. Unfortunately, the add-on software was
already configured to install and use libraries in "/usr/lib" and the
popular/default "/usr/local/lib" was included in the default linker
path so that would not have worked either.
The libtool I was using (originating from Ubuntu Linux) stripped the
rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
to embed an rpath in the libcurl I built so that applications linked
with that libcurl would find it.
The end result was that apps linked with the new libcurl tried to use
an older libcurl on the system, and failed to run.
I was unable to circumvent this issue caused by libtool.
It is useful if user-provided options have priority over built-in
optimizations in libtool.
As a user, I strongly suggest that libtool honor user-supplied options
to the configure script and provided to the libtool command line, even
while it optimizes other unneeded options away.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
rpath stripping
There is a libtool patch going around (and submitted to
libtool-patches) entitled "ltmain.sh: Fix sysroot paths being encoded
into RPATHs".
I have previous unfortunate experience with libtool doing this (I
believe that even the FSF version does some of this). Libtool
behavior prevented me from doing something I needed to do. It is
pretty common for end users (vs OS distribution maintainers) to want
to build libraries and install them to some place like /usr/local/lib
in order support modifications which are not in a similar
system-provided library. To me this represents part of the freedom
promoted by the GNU project.
This was my unfortunate experience:
While cross-compiling some software ("Curl") for a target which
already had an older install present, libtool ended up defeating me. I
wanted to produce my own libcurl and have the apps specifically
linking with it, use the libcurl that I had built. I wanted to leave
the libcurl that came with the system in place for the many other
existing apps which needed it. Unfortunately, the add-on software was
already configured to install and use libraries in "/usr/lib" and the
popular/default "/usr/local/lib" was included in the default linker
path so that would not have worked either.
The libtool I was using (originating from Ubuntu Linux) stripped the
rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
to embed an rpath in the libcurl I built so that applications linked
with that libcurl would find it.
The end result was that apps linked with the new libcurl tried to use
an older libcurl on the system, and failed to run.
I was unable to circumvent this issue caused by libtool.
It is useful if user-provided options have priority over built-in
optimizations in libtool.
As a user, I strongly suggest that libtool honor user-supplied options
to the configure script and provided to the libtool command line, even
while it optimizes other unneeded options away.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Libtool roadmap
On Fri, 25 Mar 2022, Jeff Squyres (jsquyres) wrote: Congratulations on the Libtool 2.4.7 release! (https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html) Given that this is the first Libtool release in ~7 years, should we -- the general developer community -- take this as an indication that the GNU Libtool is back under active development? If so, is there a roadmap and/or set of timeframes for future GNU Libtool work? From the above, it sounds like you are interested in being a libtool developer. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: new release?
On Sun, 6 Feb 2022, Daniel Herring wrote: In my opinion, frequent slow releases are way better than rare fast releases. That may be true for some software, but libtool has a really good test suite so if tests pass, there is high confidence of quality for the systems it has been executed on. It is abnoxiously painful to build libtool starting from git sources so hardly anyone is testing the unreleased code. Pushing out a release assures that the mechanics are working and that it is even possible to create a release. Users are much more apt to report bugs and patches against software that they can easily use. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: lt_dlopen an uninstalled library
On Thu, 25 Nov 2021, ilya Basin wrote: Loading modules is an extremely security-sensitive issue so it makes sense to require that the specified path be absolute I agree. Actually I haven't told the whole truth. My goal was to [mis]use libtool to load dynamically a regular library that is supposed to be in /usr/lib/ on Unix and at the same folder as .exe on Windows. The reason I don't link with it is my library depends on some other libraries that are not in the search path and my executable loads them first, then loads my library. This is why a wrapper script would solve it. Years ago, Gary V. Vaughan (a key libtool developer) suggested to me that dlopen() is quite portable across Unix-like systems (even Apple's OS X) and that libltdl is not really necessarily needed in order to load dynamic modules/modules. This leaves Microsoft Windows for which it it is relatively easy to use its similar facilities via LoadLibrary()/FreeLibrary(). It is true that libltdl will help on systems where library dependencies do not work properly, or where special compiler options must be used, and it can be used to emulate a loadable module in static builds. Libtool is exceedingly helpful when it is desired to be able to support static builds and it also helps for compiling shared libraries (DLLs) under Microsoft Windows. So it is worth considering using dlopen() directly. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: lt_dlopen an uninstalled library
On Thu, 25 Nov 2021, ilya Basin wrote: Hi Bob. I configured the GM build with '--with-modules', ran `make check` successfully. Then truncated the built .so files inside the 'coders/' dir to break it. Then reproduced the failure in gdb [il@reallin GM]$ export MAGICK_CONFIGURE_PATH='/home/il/builds/GM/config:/home/il/builds/GM/config' [il@reallin GM]$ export MAGICK_CODER_MODULE_PATH='/home/il/builds/GM/coders' [il@reallin GM]$ gdb --args ./tests/.libs/lt-constitute -storagetype char /home/il/builds/GM/tests/input_truecolor.miff bgr So it turned out that the test program relies on the full path to the modules dir passed to the program and it calls lt_dlopen() with the full path. I guess I'll have to set the test environment in Makefile.am. Thanks. It is interesting that this is what was causing problems for you. Loading modules is an extremely security-sensitive issue so it makes sense to require that the specified path be absolute, or written like ./foo.la. Regardless, GraphicsMagick does some things differently than perhaps the original libtool/libltdl objectives since it tries not to be too dependent on libltdl and it has its own module loader smarts. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: lt_dlopen an uninstalled library
On Mon, 22 Nov 2021, ilya Basin wrote:
Hi List.
I'm making a program with plugins as shared libraries and when I run `make
check` I want my program to load the uninstalled plugins using lt_dlopen().
I expected that passing `-dlopen libname.la` to libtool would force
the generation of a wrapper script setting the proper
LD_LIBRARY_PATH (just like regular linking with a shared .la does).
However, an ELF binary is generated and and attempt to call
lt_dlopen("libname.la") fails with "File not found". It only
succeeds if the filename contains "./.libs/". What am I doing wrong?
I am not sure what the correct answer is. Normally loadable modules
do not have "lib" prefixes and so normally one does not use a "lib"
prefix in conjunction with -module. Use of "lib" prefixes is for
shared libraries indended to be linked with using a linker (for
software compilation).
When libtool builds shared libraries and modules, it puts them in a
".libs" subdirectory. The ".la" file in the build directory should be
enough for libltdl to load the module from the hidden ".libs"
subdirectory. When the module is installed, the a new ".la" file is
created which is correct for the installed form, and the module may be
re-linked while being installed.
Feel free to look at GraphicsMagick (http://www.GraphicsMagick.org/)
source code for ideas. GraphicsMagick uses lots of modules and its
test suite works without installing the software. It does not use
libltdl's static-module "preloaded" feature.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive
On Sun, 21 Nov 2021, Alex Ameen wrote: Overall I think we're on the same page. I understand that `libtool' is ultimately intended to provide cross-platform consistency as a portability wrapper around each platform's various compilers, linkers, and loaders. It is certainly not my intention to promote a specific tool or platform over another. I am glad that our new maintainer is philosophically on the same page and also has excellent skills. I think that (similar to the influence of GNU/FSF philosophies on software development) libtool should help guide application developers to to use the most portable approaches while achieving their own objectives. From this standpoint, libtool (and Autotools in general) are not just 'tools' (like 'ld') but help guide users (developers) so that if they follow guidelines, and what the tools intend to promote, their applications are most likely to be portable and still work well. If the development/porting problem is looked at using Venn diagrams, then there would be a proportion of features/solutions in common amongst modern targets and those should be the features/solutions which are promoted by Autotools. In some cases the description of what is wanted can be at a high enough level that the desired low-level behavior can be accomplished entirely differently on different targets (because of how they work). In Autotools, the above has worked well, although there have been many complaints over the years about libtool behavior regarding explicit dependencies (via ".la" files) whereas leveraging implicit dependencies are usually prefered by distribution maintainers. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive
On Sat, 20 Nov 2021, Alex Ameen wrote: Thanks for the follow up, this gave me a much clearer idea of the underlying issue that you're trying to solve. I really do appreciate you taking the time to help improve `libtool'. You're absolutely right that `libtool' completely bungles the use of `--whole-archive' and `--no-whole-archive' which I see as a high priority issue. In several build systems I've built in the past I have needed to apply manual patches to `libtool' to work around this, and I plan on merging changes to fix this soon ( I'm taking my time to create test cases ). I don't pretend to understand the associated issues, but please take care that libtool does not promote solutions which only work with GNU ld (or linkers designed to perfectly emulate GNU ld) on a limited set of targets. Libtool is a portability solution to encourage development of software which is able to compile and run on many targets, even if the authors of the software have never experienced those targets. Linking static libraries into shared libraries is a complex topic and is a reason why libtool offers the clumsy/inefficient "convenience library" mechanism since it assures that the objects were compiled properly to be used in the library they are linked into. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Organization of ltmain.in into sub-files
On Mon, 18 Oct 2021, Alex Ameen wrote: This sounds great to me, I'd love to lend a hand. I had filled out the form a few weeks ago when I sent in patch for `/usr/bin/file' references, so that might still be sitting in the queue for review. If not, let me know and I can file a new request. The problem is that there are no libtool maintainers to service your requests. :-( This means that you would need to contact the GNU organization to express your interest in becomming a libtool maintainer. There are many pending bug reports with patches to be integrated. Your own work may collide with these patches so they can not be easily applied. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Organization of ltmain.in into sub-files
On Sun, 17 Oct 2021, Alex Ameen wrote: I thought I had seen in some TODO notes that other maintainers had been working on reorganizing `ltmain.in', so I wanted to poke my head in and see if there was an existing branch doing this sort of works, or if this was something that anyone thinks would be useful as a project branch? Right now Your work sounds like an excellent idea. The major problem for the libtool project right now is that (as far as I am aware) there have not been active maintainers for years. It seems like you have the skills required for this task. Becoming an official libtool maintainer would help move the project forward and make it easier to integrate your own ideas. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [EXTERNAL] Re: LD_LIBRARY_PATH in wrapper scripts
On Sat, 21 Aug 2021, Oleg Smolsky wrote: So, if libtool does not believe that /usr/lib/x86_64-linux-gnu is in the default search path, it adds it. Right, and my compiler is in /opt/gcc-11/ and so that addition to LD_LIBRARY_PATH is wrong. The system's compiler is older than what we use and the forced (older )version of libstdc++ breaks the executable. You should talk to the person who built and installed this compiler. I recollect that it was you. :-) Does gcc -print-search-dirs produce correct/useful output for your compiler? If the system's 'ldconfig' is not aware of your compiler's library installation, then the system will search the normal places for the libraries unless you add an -rpath option to the build. Of course if ldconfig is aware of your compiler's library installation then that causes problems if you are using multiple compilers. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: LD_LIBRARY_PATH in wrapper scripts
On Sat, 21 Aug 2021, Oleg Smolsky wrote: Hello there! We have an autotools-based build system setup with a custom GCC where we take all build- and run-time dependencies (except for glibc) from /opt. Things have worked well on Ubuntu 16, yet I'm hitting a funky issue when building on Ubuntu20 (libtool 2.4.6-14 according to dpkg). The issue comes down to one of the wrapper scripts that contains this gem: # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu:/home/oleg/project/_obj/.libs:/opt/gcc-11/lib/../lib64:$LD_LIBRARY_PATH" Most of our libs are statically linked with exception of just one. So tests/apps that use that shared lib end up with libtool wrappers... and they work correctly on Ubuntu16 (libtool 2.4.6-0.1 according to dpkg). It seems that libtool version just does not stamp out this extra variable... The manual fix is to remove the "/usr/lib/x86_64-linux-gnu" bit from the LD_LIBRARY_PATH above... and yet I have no idea where it came from or whether there is a way to influence its composition from a Makefile.am file. I think that libtool tries to deduce the default run-time linker search path (e.g. as used/provided to ldconfig, and also documented in the 'ld.so' manual page) and it also tries to learn where the compiler's own libraries are installed. So, if libtool does not believe that /usr/lib/x86_64-linux-gnu is in the default search path, it adds it. Note that the compiler's run-time libraries are installed under /usr/lib/x86_64-linux-gnu (e.g. /usr/lib/x86_64-linux-gnu/libgcc_s.so.1). The wrapper scripts are used for running programs in the build tree. They are not meant to be installed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Wed, 11 Aug 2021, Alexei Podtelezhnikov wrote: And as I prefer DLL compared to static lib, I know what to do :-) I have the distinct impression that static libraries are rarely used under Windows any more. Perhaps I am off base here. Isn’t this why DLL comes paired with a LIB wrapper, while static is just LIB. VC links with LIB regardless. That makes sense. The key issue is if the consumer of the header file wants/needs to have dllimport/dllexport enabled. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Wed, 11 Aug 2021, Vincent Torri wrote: The only solution I can see is : forcing to have only one specific library. either static or shared, and throw an error if the wrong lib is chosen at configure time. And as I prefer DLL compared to static lib, I know what to do :-) I have the distinct impression that static libraries are rarely used under Windows any more. While useful for debugging, a lot of projects just don't produce them any more. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Tue, 10 Aug 2021, Vincent Torri wrote: Perhaps better solution is use of -export-symbols. 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) This is a good point. For GraphicsMagick we just had to deal with it and provide an external way to know how the library was expected to have been compiled. This is fragile since it is possible/likely that both static and DLL are available at the same time and compiler will choose one of them according to its own rules, and especially if libtool is not used for linking against that library. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [EXTERNAL] Re: Unhelpful automatic 3rd-party library linkage
On Tue, 29 Jun 2021, Oleg Smolsky wrote: Are you absolutely sure that the above is true? You specified c++17 when compiling your application. Are the libstdc++ ABI's the same across GCC versions and C++ language versions? Well, I want to claim that I am absolutely sure :) My understanding is that there have been no ABI breaks in the GCC/libstdc++ ever (even noting the 5.x move to the Standard-compliant std::string). The general principle is to let people/distros upgrade gcc/libstdc++ in the OS and let the old apps continue running. That is a good thing. :) I am the person who maintains the compilers (installed into /opt/gcc-xx) and 3rd-party libs (installed into /opt/3p) at our shop. I don't care to update the system's compiler or libs as we don't use them at all. That is, our build system uses our compiler and only links to the 3rd-party dependencies from /opt. Been there. Done that. :-) It is possible that GCC itself is pre-programmed (e.g. via the spec file) to record this information when it links with the C++ standard library. Right, I figured this very point out just a couple hours ago - the extra flags/libs (along with the -lzmq transformation) come from the ".la" file. I've rebuilt the lib, purged the file and things look good now for my build. Could you shed some light on how this .la file is supposed to be used? I see that it tries to be helpful by capturing the dependencies... but it seems to destroy the standard `-lfoo` contract. IE it appears that it reduces the level of abstraction needlessly for artifacts that are distributed/stored. Is this ".la" thing meant only for build systems where the whole tree is built from scratch at the same time? It is true that the .la files encode all of the library dependencies which were current at the time. This is the most common complaint regarding libtool. If this was not supported for static compilation, then static compilation would not be possible. Systems which do not support implicit dependencies in shared libraries also need this. A model whereby libtool can know which explicit dependencies are desired and which should not not be recorded/replayed was never proposed. As a result, it has become common for ".la" files to be deleted or edited (they are simple text files) in order to achieve the goals of binary distributions. In your case it seems you are in complete control. You could put the most recent libstdc++ library in a common area and modify the ".la" files to refer to that one instead. If necessary provide a modifed GCC spec file to assure that the compiler itself does what you want while linking. Unfortunately, existing libraries may have implicit dependencies baked into them which will not go away without rebuilding them. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Unhelpful automatic 3rd-party library linkage
On Tue, 29 Jun 2021, Oleg Smolsky wrote: ...and I have figured out the source of the mystery linker flags: zmq build leaves libzmq.la file which contains this: # Libraries that this one depends upon. dependency_libs=' -lrt -lpthread /opt/gcc-10/lib/../lib64/libstdc++.la' It looks like automake/libtool finds this file (BTW, when is it found?) and transforms `-lzmq` into a whole bunch of things (with explicit .so names and dependencies)... Yes, that is part of the function of libtool. In fact (as you can see), the libstdc++.la file was provided with the compiler. These are features that you may love or hate depending on what you are doing. For example, if the information necessary to find the library is missing (and it is not in the default system library search path), then the program would fail to run! If a program attempts to link with a library which depends on this library, then it would fail to link, or fail to run if the library can not be found. The compilation toolchain you are using is set up to not put its libraries in the default system directories. As a result, the libstc++.so.6 file needs to be found somehow. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Unhelpful automatic 3rd-party library linkage
On Tue, 29 Jun 2021, Oleg Smolsky wrote: It looks like GCC9 references come from libzmq: $ ldd /opt/3p/lib/libzmq.so | grep libstd libstdc++.so.6 => /opt/gcc-9/lib/../lib64/libstdc++.so.6 (0x7f95f8d9f000) Obviously the 3rd-party library was built a while ago with GCC9. At the time it was linked to the compiler's runtime... but now the main application has moved to GCC11 and I'm linking to the runtime that is correct right now. It looks like automake/libtool try to be helpful and check the library's dependencies... but that gets in the way as the new libstdc++ is a strict superset of the old one. They maintain ABI compatibility and so scenarios like these are supported. Are you absolutely sure that the above is true? You specified c++17 when compiling your application. Are the libstdc++ ABI's the same across GCC versions and C++ language versions? Is there a way to suppress dependency tracking for the 3rd-party libraries? I wish Libtool/automake was not trying to be smart and simply passed "-lzmq" directly to the linker. Yet instead, the actual .so file is discovered and then its libstdc++.so is linked. This is just wrong for the scenario at hand. Assuming that the whole system does not have these directories in the default search path (e.g. via ldconfig), it appears that this is a recorded implicit dependency which is encoded in the library itself. The only way to remove such an implicit dependency is to rebuild the library (e.g. libzmq.so) with different options. If the persons who delivered the compilers to you expected that the C++ library was truely reusable, then they would not have have put everything under /opt/gcc-foo directories (also suggesting that these directories are removable). Instead they would have put the C++ run-time libraries in a standard system location. For example, under Ubuntu Linux, I see that libstdc++.so.6 is at /usr/lib/x86_64-linux-gnu/libstdc++.so.6 which is a common system directory. As far as I am aware, there is no option to request that libtool not perform the full linkage that it does. A common work-around is to remove the ".la" files that libtool produces and installs. It is possible that GCC itself is pre-programmed (e.g. via the spec file) to record this information when it links with the C++ standard library. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin
On Fri, 25 Jun 2021, Dietmar May wrote: Is this a holdover from 13 year old mingw behavior? or related somehow to running autotools in a cmd.exe environment (like Microsoft's original NT "posix" subsystem, a port of gnu commands to run "natively" under cmd.exe)? Libtool was last released in 2014. Nothing has changed since then. :-) Can libtool just ditch all of the back and forth path conversions, and simplify all of this? I am not sure what the current situation is now but MinGW compilers/tools used to accept Windows paths only because they were native Windows programs without any "POSIXization". Cygwin is a Unix emulation environment so it uses Unix-style paths. In the past, MinGW users often used MSYS. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [EXTERNAL] Re: Q: library dependencies
On Fri, 25 Sep 2020, Oleg Smolsky wrote: On 2020-09-25 09:28, Bob Friesenhahn wrote: With convenience libraries, there may be a necessary build order but the object files are not 'linked' before going into the convenience libraries (as a proper library would be) so all linking is when the final library or program is linked using the objects from the convenience libraries. Hi Bob, how would I make a "proper" library? Would that change the composition logic for my DAG of dependencies? I find info on these topics at https://www.gnu.org/software/libtool/manual/libtool.html#Static-libraries According to the docs "If you omit both -rpath and -static, libtool will create a convenience library that can be used to create other libtool libraries, even shared ones." and then "When GNU Automake is used, you should use noinst_LTLIBRARIES instead of lib_LTLIBRARIES for convenience libraries, so that the -rpath option is not passed when they are linked." Convenience libraries and 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. The final shared library or program itself surely has "dependencies" since otherwise it might not successfully link due to unresolved symbols. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [EXTERNAL] Re: Q: library dependencies
On Thu, 24 Sep 2020, Oleg Smolsky 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). While libtool convenience libraries are certainly "convenient" they can dramatically slow down the build. It takes time to do the operations associated with the ar files, but most importantly it prohibits parallelism in the build. So, I am not sure what can be done here. Could you clarify the following please: - Does the aforementioned renaming bloat the executable? Bloating of the executable depends on the object files linked with it. Linkers may vary as to how smart they are at ignoring supplied objects where no symbols have been used. - How is the linker able to resolve mutiply-defined symbols for the duplicated nodes in the DAG? 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. - Is there an alternative way to express inter-lib dependencies with automake/libtool? Using a non-recursive build and using Automake macros to express what is currently expressed as convenence libraries (using original object files in place rather than storing in 'ar' format and extracting over and over) will tremendously decrease build times. Automake supports an include syntax which allows distributing build information in the project (e.g. putting it in subdirectories next to source files) yet incorporating in single build. If everything is ruled by one non-recursive 'make', and the dependencies are properly cascading, then using Automake's non-recursive build capability will provide a huge boost to build performance, and particulary on modern multicore systems. Since you are concerned about maintenance, then of course it is wise to be aware that creating a proper non-recursive build takes work. For me, it has been completely worth it. GraphicsMagick is perhaps not the best example for how to do things since Automake has improved its capabilities since I made GraphicsMagick's build non-recursive. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Can't make dll out of a static convenience library: This system cannot link to static lib
On Sat, 4 Jul 2020, basini...@gmail.com wrote: Hi. I'm trying to build mingw-w64-gnutls 3.6.12 on Archlinux. At some point it wants to make a C++ dll out of a C convenience static library and a C++ object file, but libtool omits the static library and link fails with undefined reference. I don't understand why libtool omits the static library, because if I call g++ directly the dll is created just fine. I had to manually add `-lssp` to the command line, but I'm not sure if that's the cause. Libtool assumes that static libraries do not contain objects which are built appropriately for use in shared libraries or DLLs. Quite often objects need to be built in special ways (e.g -fPIC, dllexport/dllimport declarations) in order to work in shared libraries. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Linking with -lname key
On Sun, 7 Jun 2020, Vict wrote: Hello. Sorry if I didn't study the documentation well, but I don't understand the following aspect: why does libtool not link to its own la archives when linking with a -lname key? Since you mention /usr/local/lib, can you confirm that LDFLAGS includes -L/usr/local/lib or that this argument was otherwise supplied to libtool? Let's link a test program with libmy: $ libtool --tag=CXX --mode=link g++ -o test_app test_app.o -lmy test_app does not become dependent on libflt and libEGL (they are not in the dynamic section labeled "NEEDED". Linking test_app with absolute path to libmy does: $ libtool --tag=CXX --mode=link g++ -o test_app test_app.o /usr/local/lib/libmy.la but relying on absolute path is bad. I can’t know in advance where the library will be installed (/usr/lib, /usr/local/lib, ...). By "know in advance", do you mean that as a software developer you can't know the configuration of some other system while building, or do you mean that the libraries may be installed to some random locations? Note that when libtool is used to install libraries, it may re-link the libraries so that the results are different than with "--mode=link". You should also consider that the operating system may or may not search the directory containing the shared libraries. If it does not search the directory (e.g. /usr/local/lib in your case) and there is no run search path in the dependent library, then the dependent program won't run. You should confirm if the libtool you are using is as delivered from the FSF release, or if it is a modified version. Modified versions which change how library dependencies are treated abound. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: libtool related compile issue on msys2
On Sun, 9 Feb 2020, Torsten Kühnel wrote: Hi, i encountered 2 similar errors in an attempt to build check-0.14.0 and popt-1.16 on latest msys2. Msys2 targets native Windows APIs. I suggest consulting Microsoft's API documentation. ... ./.libs/lt-ex_output.c: In function 'main': ./.libs/lt-ex_output.c:319:16: warning: implicit declaration of function '_spawnv'; did you mean 'spawnv'? [-Wimplicit-function-declaration] 319 | rval = (int) _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz); |^~~ |spawnv A bit more detailed on https://pastebin.com/VKnYxXXm It seems like a Windows header file which declares spawnv is not being included. For libcheck the problem can be solved by using cmake to build it. But autotools/automake build system should work, too, as long as it is supported. What i hope will be until the end of the universe :) Configuring with any CFLAGS=-D_XOPEN_SOURCE=500 or such did not solve the problem. Any help apreciated. It would be senseless for -D_XOPEN_SOURCE=500 to help for Msys2 because this is an option for POSIX APIs (specifically APIs defined by XOPEN), not Windows APIs. What does this issue have to do with libtool? I have not had any problems when compiling GraphicsMagick under msys2 and GraphicsMagick is also using libtool and using the Windows spawnvp() function. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
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'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()? 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. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Sun, 5 Jan 2020, wf...@niif.hu wrote: On the other hand, this overlinks the final binary: $ objdump -p .libs/translib | fgrep NEEDED NEEDED liba.so NEEDED libb.so NEEDED libc.so.6 libb.so is unneeded here (but is present in the installed program as well). Coincidentally, the most prominent search result https://wiki.mageia.org/en/Overlinking_issues_in_packaging mentions that "this is fixed using a patch from Debian" for libtool. What's your position on this? Is overlinking a problem or not? (It causes problems for distributions.) Should everybody use --as-needed globally to combat it? Something else entirely? This has been the most common complaint (in the GNU Linux world) I have heard about libtool. There is a choice of working reliably and portably (with possible over-linking) or relying on implicit library dependencies (which are definitely not portable), or failing as you have encountered. A similar complaint is that libtool uses information in installed ".la" files in order to link with all libraries that the program/library is dependent on. Due to this, GNU Linux distributions often patch out this capability, and they don't distribute ".la" files. Unfortunately, --as-needed may not be 100% reliable since it only reliably detects direct dependence on library symbols, and not "transitive" dependence. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Sat, 4 Jan 2020, Russ Allbery wrote: wf...@niif.hu writes: Bob Friesenhahn writes: That sounds like a great idea. However, there is a problem that linking on some systems does depend on already installed libraries (or will end up using them) and so the libraries need to be installed and linked in a particular order. Do you happen to know which systems these are? Where are these constraints documented? It's been a very long time since I've built shared libraries for any platform other than Linux, but my distant recollection is that AIX and HP-UX encoded the full path to the dynamic library against which a binary was linked. Therefore, if you built an executable against uninstalled libraries, the executable would have a reference to the build directory, hence the explicit relinking step after installation to pick up the new paths. I seem to recall that we caused an outage for campus AIX systems because of this; I'm less sure about HP-UX. I don't remember whether this also applied to interdependencies between shared libraries (or if those platforms even supported encoding dependencies in shared libraries; a lot of platforms didn't). I vaguely recall that mutually-dependent shared libraries were actually impossible on at least some UNIX platforms, and thus not portable. The above matches my own memories. I do not know the current level of usage for AIX or HP-UX but expect that they are still used for business purposes because at various times they were market leaders and offered the type of support that large businesses needed for critical systems. Mutually-dependent shared libraries are to be avoided in any case. Using Autotools, I do not recall any particular effort involved with supporting AIX, HP-UX, or even IRIX in GraphicsMagick builds. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Sat, 4 Jan 2020, wf...@niif.hu wrote: ... Above dependency explain all - lib_LTLIBRARIES is project (sample) specific. Project should ensure order. Fair enogh, but my point (which I didn't really emphasize) is that installation could work in any order, if relinking didn't depend on already installed libraries. It's even necessary for mutually dependent libraries. That sounds like a great idea. However, there is a problem that linking on some systems does depend on already installed libraries (or will end up using them) and so the libraries need to be installed and linked in a particular order. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Fri, 3 Jan 2020, Richard Purdie wrote: Libtool must also work for static linking. It seems to me that your issue also impacts static linking. I think the challenge that libtool has here is that many of these older systems that libtool supports aren't so prevalent anymore. This is true. It is possible that support for some archaic compilers and systems should be removed since there is no way to verify that the support works anymore, and there might not be any more active users. Regardless, libtool must continue to support static linking, even if deployment usually uses dynamic linking. As a developer, I use static linkage for daily development yet recommend dynamic linkage for most deployments. We have a number of libtool patches to sort cross compile issues which really need discussion with upstream libtool. With the lack of releases, our incentive to do that diminishes :(. You can become part of upstream libtool and commit your fixes directly. Finding new maintainers with the amount of knowledge of weird older systems needed is going to be a struggle which only gets worse over time :( Most systems are not so weird. Most problems with legacy targets have been due to shell and common utility differences/bugs (e.g. depending on 'bash' syntax or behavior of 'echo'. These problems are due to the Autotools assumption that Autotools should be able to work with the shell and utilities that originally came with the system. If it is impossible to find a representative target system to test on, then that is an indication that support should be deprecated. Users of unpopular systems need to stand up for themselves and assist, even if only by providing remote access to test on the system. I do worry about the future here as libtool is a key part of the autotools fabric but its most likely to be wholesale replaced given how things are trending. The current trend is that all of Autotools at risk even though it still works pretty well. Perhaps Automake is in best shape since it was released most recently. Autoconf has continued to be developed, but has not been released. Autoconf 2012 libtool 2014 Automake 2017 Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Thu, 2 Jan 2020, wf...@niif.hu wrote: If Libtool were to depend on non-portable features, [...] then it could not longer be described as a portability tool. In my understanding, Libtool is a portability shim, providing a regular interface for developers across systems with wildly varying features. It already uses non-portable features, just different ones on different architectures. I don't say it should use -rpath-link generally, I only suggested that it might be an efficient solution on systems supporting it. But I expect all systems supporting shared objects to allow using and installing them some way, irrespective of their interdependencies. Am I overly naive? Certainly, libtool could use -rpath-link where it is supported but libtool provides a common feature set and if it is only possible to support a feature where -rpath-link is available, then offering the feature would defeat the purpose of being a portability tool. Sometimes it is better to force the using software to conform to the limitations. Libtool must also work for static linking. It seems to me that your issue also impacts static linking. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Thu, 2 Jan 2020, wf...@niif.hu wrote: True, but man ld states in the -rpath-link option description that the directories specified by -rpath options are used with a very high priority for locating required shared libraries. This is interesting but I am not seeing any use of -rpath-link in libtool. Neither do I, but I think it would be a possible way out of this situation. I wonder what the reason could be for libtool not using it. Libtool is a portability tool. If it were to depend on non-portable features, then software would be implemented using it which is non-portable and the software developers might not be aware of it. If Libtool were to require GNU Linux, or GNU ld, or GNU gcc. or GNU libc, or ELF, then it could not longer be described as a portability tool. Indeed, if one makes some assumptions and is willing to lose some portability then it is not difficult to use underlying tools directly, without using libtool at all. At one time it was assumed that GNU software would reach the largest number of potential users by being implemented in a portable fashion. An alternative would have been to require that GNU software can only be compiled on GNU systems (this would have been impossible to start with since such a system did not exist) using GNU tools. It's rather hard to get support for libtool, but I sorely need some, because this issue hurts a real software project. Since this is the first time I seriously deal with libtool, I certainly miss most of the picture, so I sincerely appreciate your "piping up". Let's hope others will join with time with their insights. As far as I am aware, libtool is currently "between maintainers" and needs fresh volunteers to become a libtool maintainer. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Thu, 2 Jan 2020, wf...@niif.hu wrote: In this case libtool is a slave of Automake and Automake is controlling the build and installation order. This means that it should be expected behavior. Installation is serialized and thus order matters. But in case of a dependency cycle there's no correct order if libtool insists on using the installation directory for the -L option for relinking. And the installation directory may contain an incompatible version of the library anyway, just like it happens below. Indeed, sometimes it is necessary to re-organize libraries and code in order to be successful given serialized linking. and use it from liba, linking the final binary fails: $ make [...] /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o translib translib.o a/liba.la libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so -Wl,-rpath -Wl,/tmp/translib/lib /usr/bin/ld: a/.libs/liba.so: undefined reference to `b2' As I understand it, the -rpath linker option on the above command makes a/.libs/liba.so use the already installed (old) version of libb, which lacks the b2 symbol. What's the solution here? Why isn't that -rpath option "delayed" until the relinking phase? The -rpath linker option did not cause the library to be used. The above gcc linking command is successful if I omit the -rpath option. (The built-in RUNPATH of liba.so contains the build directory first. Just for the record: Debian's ld defaults to --enable-new-dtags.) I am not sure exactly what --enable-new-dtags means, but Ubuntu 18.04 LTS's manual page says that this is not its default. This may indicate changing behavior. The '-r' in -rpath stands for 'run' and thus it is a path stored in a built shared library or executable which tells it where to search for other libraries when th program is executed. True, but man ld states in the -rpath-link option description that the directories specified by -rpath options are used with a very high priority for locating required shared libraries. This is interesting but I am not seeing any use of -rpath-link in libtool. Perhaps the controlling parameter is hardcode_into_libs. If your libtool comes from an OS distribution rather than from a FSF/GNU tarball, then it is possible that its behavior may have been modified. I don't know what to expect, here's what I can see: $ ./libtool --config | fgrep hardcode_into_libs hardcode_into_libs=yes I am not seeing 'libb' mentioned on the link line and that may be the cause of the problem you are seeing. Sure enough, adding libb.la explicitly to the link command works around the issue, but since the binary does not use libb directly, it doesn't sound like a good solution to me, because it leads to overlinking. Libtool can only know what has been passed to it via the command line and via the prior information it stored in the .la files (initially found due to the command line). I have always found it to be good practice to include all dependency libraries in an Automake 'LIBADD' statement so that all dependency libraries are passed to libtool. If the .la file passed to libtool mentions the dependencies, then libtool is supposed to do the right thing. At this point I am wondering why I am the only person on this list who has piped up with some sort of a response. :-( Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
On Wed, 1 Jan 2020, wf...@niif.hu wrote: make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib' make: *** [Makefile:798: install-am] Error 2 No cyclic dependencies here, so this can be worked around by -lib_LTLIBRARIES = a/liba.la b/libb.la +lib_LTLIBRARIES = b/libb.la a/liba.la in this case; is this expected (and documented) behavior? In this case libtool is a slave of Automake and Automake is controlling the build and installation order. This means that it should be expected behavior. Installation is serialized and thus order matters. and use it from liba, linking the final binary fails: $ make [...] /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o translib translib.o a/liba.la libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so -Wl,-rpath -Wl,/tmp/translib/lib /usr/bin/ld: a/.libs/liba.so: undefined reference to `b2' As I understand it, the -rpath linker option on the above command makes a/.libs/liba.so use the already installed (old) version of libb, which lacks the b2 symbol. What's the solution here? Why isn't that -rpath option "delayed" until the relinking phase? The -rpath linker option did not cause the library to be used. The '-r' in -rpath stands for 'run' and thus it is a path stored in a built shared library or executable which tells it where to search for other libraries when th program is executed. The libtool configuration may be dumped using ./libtool --config Perhaps the controlling parameter is hardcode_into_libs. If your libtool comes from an OS distribution rather than from a FSF/GNU tarball, then it is possible that its behavior may have been modified. I am not seeing 'libb' mentioned on the link line and that may be the cause of the problem you are seeing. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
On Wed, 26 Jun 2019, Roumen Petrov wrote: but this is error-prone because some other toolchains might use a different C++ library. Oracle Solaris 11 with the Solaris Studio 12 compiler supports a large number of C++ runtime libraries as described at https://docs.oracle.com/cd/E37069_01/html/E37075/bkaje.html When dealing with C++, one must know what one is doing. The only portable way to link with C++ is by assuring that the main() function is in a C++ module. If the C++ compiler is intentionally used to link using the other options supplied to the compiler, then the correct libraries will be automatically selected by the compiler. On a typical GNU Linux or FreeBSD system, all C++ software is built using the same C++ runtime libraries (at some specified C++ standard level). This is accomplished through brute force by the OS package maintainers. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
On Mon, 24 Jun 2019, Roumen Petrov wrote: Reporter still does not provide feedback with information from configuration time (requested in a previous post) => resolution is - broken build environment. I think the problem is an unreasonable expectation which is becoming more unreasonable as time goes by. C++ supports exceptions and C does not. If the run-time used does not provide an exception handling framework then there will be a core dump either when the C++ exception is initially thrown, or at the boundary of C/C++. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
On Sun, 23 Jun 2019, Yuri wrote: So is there an easy way to override this and always use C++ way of linking? To do this you might need to set LD or CC to your C++ compiler. A better way is to make your main program be C++ since that assures it can work. Consider that C++ exceptions can not be thrown into C code unless a special compiler option is used so that C supports the exception framework. Without this you are likely to get a core dump. C++ is very good at using C code but C code is not very good at using C++ code. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
On Sun, 23 Jun 2019, Yuri wrote: Those variables could be used to tune build process. For instance CXX=my-c++ ./configure ... could be used to change C++ compiler. It seems to know that c++ is the C++ compiler, but then uses cc anyway: I doubt that libtool can be smart enough to intuit when the C++ compiler needs to be used for linking when the program being linked is C. The only way it could tell this is via library dependencies. Just supplying the library dependencies is not enough. C++ introduces a new wrinkle in that there are now often 3 or 4 different C++ variants available based on C++ standard level, and library options (e.g. different C++ STL library implementations). Things have changed quite a lot in the past several years when it comes to C++. In addition to being linked using the C++ compiler, the correct options would need to be passed to the C++ compiler so that the correct standard level and libraries are used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
On Sun, 23 Jun 2019, Yuri wrote: On FreeBSD libtool can't find operator new[] because it is in C mode: How to switch libtool to the C++ mode? Are you using expected file extensions for C++ code? Is your main program a C++ module or a C module? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Avoid -Wl,--whole-archive
On Thu, 16 May 2019, Tim Rühsen wrote: Hi, at GNU Wget2 we are just splitting a (shared) library into several smaller ones, grouped by functionality. We depend on gnulib and have a single libgnu.a. Each of the shared libraries just need a certain set of functions from libgnu.a. To avoid adding everything from libgnu.a to each of the libraries, we would like to avoid "-Wl,--whole-archive ../lib/.libs/libgnu.a -Wl,--no-whole-archive". There is no requirement to use "convenience" libraries. People who do things due to "convenience" are often classified as "lazy". :-) If you have time to re-do your build structure, then I recommend using a non-recursive build and explicitly listing the objects which are needed by each library in the single Makefile. Objects common to multiple libraries will then be built just once and supplied to the linker as a list of object files rather than fed to libtool like an "archive" file which is then split into object files actually supplied to the linker. Convenience libraries are evil. Convenience libraries slow down your build process dramatically and they cause 'make' not to be aware of the actual underlying dependencies, so that it does much more work than is required each type you invoke 'make'. If you can enumerate the actual dependencies in the Makefile and avoid needless intermediate product generation, then you will achive a maximally parallel build which builds much faster on modern systems. If your project is already fully built, then typing 'make' again should return almost immediately without doing any work at all. If your project does any work at all due to typing 'make' a second time, then it is defective. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt___ https://lists.gnu.org/mailman/listinfo/libtool
Re: GCC LTO options not correctly handled
On Fri, 12 Apr 2019, Laurent Stacul wrote: As I don't have the ownership on the project, I need to patch (and provide a patch upstream). But this can be tedious on big projects, so it would great if libtool don't filter the options like -fno-lto, -fno-whopr. The path of least resistance is to use the GCC -Wl, or -Wc, syntax to pass options to the linker or compiler, respectively. This already works well with Autoconf, Automake, and libtool. Adding support to libtool to support particular GCC options is the path of greatest resistance. Compiler and linker options tend to expand continually, and it is not reasonable to support them all. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Regd. use of libtool in commercial applications
On Thu, 14 Mar 2019, reshmi ravindranathan wrote: 1. Please advice if there are any specific licenses for commercial applications. Please share if any. 2. Is it possible to get some community edition of libtool Please read the license at the top of ltmain.sh. It includes: # As a special exception to the GNU General Public License, # if you distribute this file as part of a program or library that # is built using GNU Libtool, you may include this file under the # same distribution terms that you use for the rest of that program. There are also special exceptions if you use libltdl. It is good that you are interested in complying with the license. You are responsible for reading the license text for each involved component and making sure that you follow the license. I am not a lawyer, but it is my opinion that if you use libtool as it is intended to be used, you may use it as part of a "proprietary" application. There are usage models where this is not true. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Cut a new release?
On Thu, 27 Sep 2018, Robert Boehne wrote: I would be more than happy to cut a release, if only I could remember how. I think the last version I released was 1.5.x - I'll look around but if anyone on the list remembers where the instructions are - please help me out ;) I think that there are useful instructions in the libtool source repository. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Cut a new release?
On Fri, 21 Sep 2018, Samuel Tardieu wrote: Libtool is in need of additional volunteers to serve as maintainers to help catch up on the backlog of patches/issues and prepare another release. My question was solely about tagging and cutting a new release from the current state of the repository so that patches contributed by volunteers and accepted in the repository already get a more widespread distribution. Volunteers with the necessary energy, time, and resources are necessary in order to perform this function. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Cut a new release?
On Fri, 21 Sep 2018, Samuel Tardieu wrote: Would it be possible to cut a formal release? Libtool is in need of additional volunteers to serve as maintainers to help catch up on the backlog of patches/issues and prepare another release. Are you able to volunteer to be a libtool maintainer? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Apple OS ACL files in libtool distribution tarballs
On Tue, 17 Jul 2018, Eric Bavier wrote: Hello Libtoolers, I noticed that at least the last two distributions of libtool (2.4.5 and 2.4.6) contain "._*" files in the tarballs. AFAICT these are from OS X's tar, which "uses AppleDouble files to store extended attributes and ACLs'. These files are only meaningful on OS X, and don't seem like they should be distributed. Probably not a huge deal, just thought I'd point it out. This is a known issue and it is unlikely to happen again. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Does libtool need to escape plus signs in egrep expressions?
On Thu, 28 Jun 2018, Roumen Petrov wrote: May be I misunderstand issue. $ echo ' _head_ABC_a' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' _head_ABC_a $ echo ' _head_ABC_al' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' _head_ABC_al but: $ echo ' _head__al' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' $ echo ' __head_ABC_al' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' $ echo ' _head_ABC_zl' | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$' Are you sure this actually works? I'm not expert in regular expressions but according above tests "plus" in RE works - see case _head__al . It should match a run of alpha-numeric characters including underscores. However, I do see that the expression includes a match of literal underscore and then there is a literal underscore so there might be something going on with that. Greedy matching would likely absorb a final underscore so it might not be possible to match on that final literal underscore. This might expose differences in behaviors between egreps. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
On Thu, 21 Jun 2018, John Calcote wrote: Hi Bob. It's an ubuntu distro release - Linux Mint 18. Why would they do that? GNU Linux and the GNU linker support implicit library dependencies. When a library which implicit library dependencies is linked, the libraries it depends on to successfully link are automatically added by the linker, but are not additionally recorded as dependencies. The implicit dependencies (and explicit dependencies) are again used when the program is started by ld.so. Using implicit library dependencies successfully is actually a bit of work but it is very useful to OS distributions which want to update libraries (or groups of libraries) via a package manager without needing to update dependent applications or libraries. The normal libtool operation is to record all of the involved libraries as dependencies since they are all added to the link line. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
On Thu, 21 Jun 2018, Paul T. Bauman wrote: This is correct and bit us as well when Debian-based systems changed this. Our very hackish work around was to insert the following in our configure.ac immediately after AC_OUTPUT(): perl -pi -e 's/link_all_deplibs=no/link_all_deplibs=yes/' libtool OS distributions where shared libraries provide robust implicit dependencies, and where pkg-config or other methods are used to obtain build options, do not like what libtool does. They do not like that libtool adds libraries that the application/library did not explicitly link with. The reason why they do not like this is that if they introduce a different library which has different dependencies then they would like the dependencies to be entirely determined by the new library. This is a very long-standing point of contention. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
On Thu, 21 Jun 2018, John Calcote wrote: After upgrading to libtool 2.4.2, I find that I now have to specify the additional secondary .la files that are listed in the primary .la files' dependency_libs property, or I get a link error indicating missing DSOs on the command line (and I can see that libtool is not adding the transitive dependencies like it used to. Why was this change made? Are you using libtool 2.4.2 as distributed by the FSF or are you using a modified libtool distributed by an OS vendor? Some OS vendors modify libtool like this on purpose. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: visibility support
On Fri, 9 Feb 2018, Alexei Podtelezhnikov wrote: Which LT_INIT option would enable the hidden symbol visibility support? Libtool is all about supporting a core set of features in a portable way. It is not about my use case, which I solved, it is about making -fvisibility=hidden into a core Libtool feature. I will summarize and never bother you again. You make very good arguments. The question remains as to who would implement this feature, test it, and assure that it gets in a libtool release? Are you willing to take responsibility for this? It is a lot of work, but libtool exists due to the effort of volunteers who were willing to do a lot of work. There needs to be a fall-back mode on systems where the request can not be supported. Luckily, the fall-back mode for this feature (simply ignore the request) is less draconian than the fall-back mode for the win32 option. The setting might need to be remembered in the installed .la files in order to know if libraries this library depends on are also prepared for the feature, and for libraries that depend on this library can know that they can use the feature. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: visibility support
On Fri, 2 Feb 2018, Alexei Podtelezhnikov wrote: Dear all, Which LT_INIT option would enable the hidden symbol visibility support? There is no such thing in libtool as far as I am aware. Libtool is all about supporting a core set of features in a portable way. There is nothing to prevent you from doing what you want in your configure script by adding to CFLAGS and/or LDFLAGS variables. Just make sure that enabling or depending on this feature does hinder portability to systems which do not support the feature. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Colons not escaped for setting LD_LIBRARY_PATH.
On Fri, 2 Feb 2018, Philipp Thomas wrote: The wrapper script created by ltmain 2.4.6 on Linux sets LD_LIBRARY_PATH as an absolute path. Unfortunately it doesn't escape colons and the colon is the delimiter for paths in LD_LIBRARY_PATH. So the exe doesn't find its library. Could someone help me locate the place where I could modify the escaping? Are you saying that your system includes colons in its filesystem paths? That would definitely be problematic. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: How can I get rid of the -L entry of LDLIBS from RPATH?
On Mon, 31 Jul 2017, Krisztian Kovacs wrote: Hi! I haven't seen any examples how to set these script variables: https://www.gnu.org/software/libtool/manual/html_node/ libtool-script-contents.html#libtool-script-contents Can are they set per project? If so, how? All libtool script content is generated by 'configure' as described. In many cases, configure arguments may be used to set/override values (e.g. 'CC'). Many of these values may also be obtained from the shell environment in which configure is run. A config.site script (e.g. /usr/local/share/config.site) may be used to set default values for most variables set or used by configure and may be used to remember any settings found in the generated config.status script. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: ./libtool[1086]: eval: syntax error at line 1: `|' unexpected
On Thu, 30 Mar 2017, Jeffrey Walton wrote: If I am parsing things correctly, the "unexpected |" is due to a missing command. Solaris is very Posixy, and I'm not sure which command may be running afoul. Parts of Solaris are very Posixy and other parts are not. Unless things have changed in the past several years, the legacy /bin/sh shell is not very suitable for running configure or libtool. On my Solaris 10 system, there is /usr/xpg4/bin/sh which tries to be more compliant (it is likely a link to ksh93 under Solaris 11), and bash is always available. Configure will usually select bash on Solaris sytems. The selected shell is set in the CONFIG_SHELL environment variable and the user is able to over-ride this. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool support for LLVM's LLD linker
On Tue, 21 Mar 2017, Ed Maste wrote: On 9 January 2017 at 19:17, Ed Maste <ema...@freebsd.org> wrote: I am (with a few others) trying to build all of the applications in the FreeBSD ports tree using LLVM's LLD as the linker. We've been making great progress linking software in the FreeBSD ports tree with LLVM's LLD. Unfortunately, libtool is currently the largest portability problem we're facing (in the context of LLD), and this now applicable to LLD on at least other BSDs and Linux. There's a proposal[1] to have LLD include "compatible with the GNU linkers" in its version info so that libtool treats it like GNU ld / gold. Going down this user-agent-alike path in toolchain components is rather unfortunate, and I'd really like it if it can be avoided (at least in the long term) by having libtool itself treat LLD as GNU ld. For more information see the mailing list thread[2] that prompted this patch. What bad things happen if libtool does not decide that the linker is GNU ld? Does the situation improve if --with-gnu-ld is supplied as an argument to configure? If this causes things to work, then it is a way for the ports system to cure the problem at configure-time. Regardless of what happens with libtool in the long term, the situation for LLVM's LLD will be much better if it pretends to be GNU ld since it takes years to deploy a new libtool release across OS distributions. Clang pretends to be GCC in many ways. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?
On Thu, 16 Feb 2017, Nish Aravamudan wrote: I do not believe so, the tests (heimdal self-tests) are run via a Makefile target which calls the generated wrapper script(s). Normally if you call the generated wrapper scripts, things should be ok, as long as the linkage was correct in the first place. I really appreciate the response! From what I can tell, though, the temp_rpath variable is not actually used to compile/link anything, it's only used for the wrapper script generator. And I don't understand how it would be correct for an explicit LD_LIBRARY_PATH specification (as done by the wrapper generator) to have the system library path anywhere before the end of the list. Otherwise, if any of the required library dependencies are installed, the somewhat arbitrary set before the system library path in LD_LIBRARY_PATH will use the built libraries and the somewhat arbitrary set after the system library path in LD_LIBRARY_PATH will use the system libraries without any indication of a problem -- and it becomes rather murky what is actually being tested. I don't think that it is normal or ok to have the system library path in the list at all. Perhaps libtool is not determining that the path is a system library path. Check the output of './libtool --config'. Particularly, sys_lib_dlsearch_path_spec. Maybe it is wrong. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?
On Thu, 16 Feb 2017, Nish Aravamudan wrote: I am trying to get to the bottom of an odd build failure on Ubuntu 17.04 with heimdal. I believe the underlying issue is a bug in libtool, but I'm not confident in my analysis (some of it is also at https://github.com/heimdal/heimdal/issues/241), but here's what I have, I would appreciate any feedback! Using the system sqlite3 (/usr/lib/x86_64-linux-gnu/) via configure, we end up inserting the above path into LD_LIBRARY_PATH for build-time generated wrapper scripts and since we also happen to have heimdal libraries install at the system-level, the system heimdal libraries are used by the tests instead of the build-local ones. This is bad for two reasons: a) it fails in this case because of an ABI mismatch and b) we are trying to test the built libraries, not the system installed ones when the library in question is built by this package. Do your test cases use ./libtool --mode=execute ./testprogram or equivalent to assure that ./testprogram is executed with correct library paths? It seems like there is rarely, if ever, a case to put a system library path before a non-system library path in the wrapper script, and in particular, it seems like ltmain.sh actually detects adding the system path to compile_rpath and finalize_rpath. Is it correct to do the same elision in temp_rpath? e.g. Without studying the details, it is worth noting that other software delivering libraries does manage to successfully test the uninstalled libraries even if installed libraries are present. For operating systems where this is deemed not possible (or which hard code paths to the libraries used), libtool builds with hard-coded run-paths and then re-links at install time. Problems could still occur if a library used has a hard-coded run path baked into it so that the undesired directory is still used. Problems could also accur if libraries are linked in the wrong order (e.g. building/linking in the wrong order in a recursive build) or with wrong paths such that a system library was used. I am definitely aware of issues under Microsoft Windows, which does not seem to offer sufficient control of where files come from. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against static libraries in Windows (MSYS)
On Mon, 27 Jun 2016, Bob Friesenhahn wrote: The good news is that libtool will already automatically link dependency libraries when you build something which depends on 'A' and the .la file for 'A' is present. In other words, libtool should handle the problem automatically as long as you don't do something to intentionally break it (e.g. delete the .la file) or link using something other than libtool. This is a core function of libtool. I failed to mention that there is something about MinGW which does make things different. Windows DLLs do not allow undefined symbols so you may be forced to build your library 'B' as a DLL in order for library 'A' to sucessfully link. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against static libraries in Windows (MSYS)
On Mon, 27 Jun 2016, Alex wrote: $ ./configure --disable-shared --enable-static --prefix=/usr $ make && make install But when I build *A* afterwards the following warning appears: *** Warning: This system can not link to static lib archive /usr/lib/ libogg.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. Has anybody come across this? Is there any known fix or workaround? This is a common problem, which is not specific to MinGW or MSYS. The two possible solutions are to either arrange to link with 'B' while linking any application which depends on 'A', or else build 'B' as libtool convenience library so that all symbols from 'B' now become part of 'A'. Since in this case, the user may not expect symbols from libogg to be part of library 'A' (and perhaps multiple libraries similar to 'A' may also want to link with it), I doubt that the libtool convenience library approach is the correct one here. Duplicate symbols due to mutual dependence need to be avoided. The good news is that libtool will already automatically link dependency libraries when you build something which depends on 'A' and the .la file for 'A' is present. In other words, libtool should handle the problem automatically as long as you don't do something to intentionally break it (e.g. delete the .la file) or link using something other than libtool. This is a core function of libtool. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: How to make a C++ -module?
On Tue, 21 Jun 2016, Robert Boehne wrote: Patrick, Did you build the compiler yourself? Basically Libtool is saying you only have a static version of your runtime library, so if you built the compiler yourself, add --enable-shared when you configure. If not, I'll see if I can get a NetBSD VM up and running so I can reproduce your problem, but at first glance it appears to be your compiler. I am only seeing a static libgcc.a for my own GCC builds for Solaris and also for the GCC provided by Ubuntu. To me the -lgcc seems suspect. If it is really needed then libtool would need to ignore it when the module is built (as it does) and then the application using the module would need to link with -lgcc. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: How to make a C++ -module?
On Tue, 21 Jun 2016, Patrick Welche wrote: I'm trying to create a C++ loadable module. I thought it would be as easy as: [ stuff removed ] This fails with: /bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2 -module -avoid-version -o hellow.la -rpath /usr/local/lib hellow.lo *** Warning: linker path does not have real file for library -lgcc. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgcc and none of the candidates passed a file format test *** using a regex pattern. Last file checked: /usr/lib/libgcc.a Presumably, this means that things aren't as simple as I thought. What am I missing? Nothing is easy when it comes to C++-based modules. Risks are elevated if a C-based program uses C++-based modules due to unhandled C++ exceptions or C++ exceptions possibly not working. You are going to need a shared library for the (correct) C++ run-time as well as libgcc_s.so. These need to somehow appear where libtool is searching for them. They will also need to be available in a path where the system searches for shared libraries in order to load the module. # Dependencies to place before and after the objects being linked to # create a shared library. predep_objects="/usr/lib/crti.o /usr/lib/crtbeginS.o" postdep_objects="/usr/lib/crtendS.o /usr/lib/crtn.o" predeps="" postdeps="-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc" I am not sure what libgcc is used for. It seems to only ever be delivered as a static library in the GCC installation tree. Its appearance in the link line may be a bug (possibly a bug in GCC). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: How to build libtool from git sources properly?
On Wed, 18 May 2016, Igor Zhbanov wrote: run `./bootstrap` -mike It doesn't work on a PC without git or without network connection because it needs to clone gnulib (although there is no gnulib folder in libtool-2.4.6.tar.gz. But this is probably another story. This is very unfortunate. I am not sure if it would work if you cloned gnulib on another computer and copied the gnulib folder into place since it may still make subsequent git accesses. The bootstrap requirements make it difficult to support or test on targets which can not run git or don't have network access. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool not creating version info symlinks during make install
On Sun, 13 Mar 2016, mar...@saepia.net wrote: I have found out that libtool script in the broken library generated while running ./configure --prefix /root/cerbero/dist/android_armv7 --libdir /root/cerbero/dist/android_armv7/lib --disable-maintainer-mode --disable-silent-rules --disable-introspection --host=arm-linux-androideabi has version_type=none while one that builds has this variable properly set to linux. That difference later causes libtool to not add symlinks. Can anyone here give me any hint where should I seek for what causes invalid host recognition while generating libtool? I would guess that it does not know what to do based on your host specification. Perhaps 'androideabi' vs 'gnu' throws it off. Does Android use the same shared library conventions as GNU/Linux? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-ltdl-devel
On Tue, 1 Mar 2016, Sam Knuijver wrote: Hello, how do I download libtool-ltdl-devel ? I want to install it from source since I can't apt-get it on Ubuntu 15.04 thanks The original source code may be downloaded from "ftp://ftp.gnu.org/pub/gnu/libtool/;. This might not be the same code that Ubuntu offers. Ubuntu is obligated to provide you with the source code since this is a GPL-licensed package. If they have not made it clear to you how to obtain the source code, then there is a problem. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On Fri, 12 Feb 2016, Evgeny Grin wrote: option is NOP for anything except W32 and AIX. Moreover, if it does matter only for W32 and AIX, let's rename it to "-w32-aix-shared-compatible". And add more flags, like "-linux-compatible", "-open-bsd-compatible". This will signal libtool that developed checked compatibility of build system with specific OS. We don't do this sort of thing since we have no control over the future and don't know what the future will bring. So we use generic options. If we try to guess what the future may bring then we may guess wrong and someone will take us to task about our bad decisions. For AIX, there is a build mode where shared libraries are more like GNU Linux and not like DLLs. Anyway, what's drawback of assuming "-no-undefined" on W32 and AIX (or on all platforms)? As previously explained, it is more likely to lead to compilation success for packages which have not been crafted/tuned to succeed on targets where -no-undefined makes a difference. A core Autotools principle is that the person compiling the software should be in control as much as possible. This includes people who just received a tarball and are not the developer of the software. Another core principle is that defaulting to imperfect success is better than utter failure. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On Thu, 11 Feb 2016, Evgeny Grin wrote: Repeat once more: with OS-specific code parts you can't add "-no-undefined" unconditionally. GraphicsMagick (which compiles on a wide variety of systems, including Windows and AIX) has been specifying -no-undefined as a standard option (used on any OS) in its makefiles for as long as I can remember. No harm was encountered due to this. This discussion is feeling rather Shakespearian. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On Thu, 11 Feb 2016, Evgeny Grin wrote: On 10.02.2016 18:51, Nick Bowler wrote: The default (on all platforms) is to create both static libraries and, when possible, shared libraries. This statement is ether not correct or incorrectly documented. Currently "configure --help" show those lib options by default: --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] build static libraries [default=yes] There is not "=auto" option for shared or static versions. Only "yes" or "no". So, it's explicitly specified whether static will be created and whether shared will be created. So "make" must ether create requested versions or fail. These are 'enable' options. Use of 'enable' implies "best effort". Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On Wed, 10 Feb 2016, Evgeny Grin wrote: As result - "-no-undefined" is used only on W32 without any practical benefit: if lib have some undefined symbols, it will not be build on W32 as shared lib regardless of "-no-undefined" flag. And conditionally used The "-no-undefined" option is not actually Win32 specific. IBM's AIX has build configurations which benefit from it. Also, "-no-undefined" does not indicate if the library has undefined symbols (many DLLs have undefined symbols). It indicates that the build configuration has agreed to supply any additional dependency libraries if there otherwise would be undefined symbols. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: MSW DLLs support in libtool
On Tue, 9 Feb 2016, Nick Bowler wrote: 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. This is not really true. For example, the linker on GNU Linux implicility supplies libraries at link time (because of how they were built) and libtool has no way to know about library dependencies which are not listed in .la files. Some GNU Linux distributions intentionally modify libtool such that dependency libraries are not included and they delete all .la files. The reason for intentionally losing dependency information is because the specific dependencies cause packaging problems. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re[2]: MSW DLLs support in libtool
On Wed, 10 Feb 2016, Vadim Zeitlin wrote: Sorry but this is just not true for the MSW DLLs. If the libtool user tries to build a DLL, you can safely assume that it will not have undefined symbols. Anything else just doesn't make sense because it would always result in an error. Again, this is different from the traditional Unix shared libraries. Why do you say this? Most software built using libtool still comes from Unix type systems. Without the existing behavior it would be difficult to take a program developed on a Unix type system and just compile it under Windows. It is thought that errors are bad and successful compilation is good. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
On Fri, 5 Feb 2016, Harald Servat wrote: I'm unsure on how to interpret the libtool related information because it is very simplistic configure:11699: checking if libtool supports shared libraries configure:11701: result: no however, at some point earlier, the following test might be related configure:8998: checking whether the fccpx linker (sparc64-linux-ld -m elf64_sparc) supports shared libraries configure:10069: result: no Can we provide some additional info or run additional tests to improve libtool on this system? The generated config.log file contains detail information regarding the tests performed and error messages produced. Looking there is the next step. The '-print-search-dirs' error message is because libtool attempted to treat the compiler like GCC and obtain its default linker search path. It is unfortunate if Fujitsu does not care to contribute. If that is indeed true, then that would be their loss since a large portion of free software packages use Autotools (including libtool) and these packages won't compile as effectively if the target is not supported. Fujitsu's system would be barren of commonly available software. Fujitsu is in the best position to support their own compiler and platform. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: how to make libtool use stdlib
On Tue, 8 Sep 2015, Andy Falanga (afalanga) wrote: I'm working on a library which may need to link with the standard libraries (I assume since -nostdlib would seem to indicate that it's *not to* link with standard libraries). I say this because of discussions I've come across making mention that using "-nostdlib" has adverse side effects with pthreads. I'm using a library, log4cplus, which does make use of pthreads. Using "./configure --help" doesn't reveal any method of making libtool discontinue the use of "-nostdlib". How do I make this happen? Libtool normally queries GCC to learn what libraries it would normally apply and carefully applies them anyway. Is this not working for you? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: cross-compiling with libtool
On Thu, 14 May 2015, Lane wrote: That's what I don't understand. I do have a ranlib binary and it is named by the cross-tools environment that I've been given. For some reason it's not able to find it though when running make install and I don't know how that happens. Are you running 'make install' as a different user than the user who did the build? If so, the PATH, LD_LIBRARY_PATH, or the ability to execute the binary may be different. Check the PATH, LD_LIBRARY_PATH, and the permission bits on the executable. If this 'ranlib' is a script rather than a true binary (not uncommon for transplanted cross-tools), then check its first line to see if the shell it requests is valid and allows execution by that user. Lastly, the toolchain binaries might be a different architecture than the native architecture for your machine. For example, they might be i386 and/or x86-64. If the user id, PATH, or LD_LIBRARY_PATH, changes, perhaps this is causing binaries not to be runnable any more. I have seen cases before where binaries for a different architecture were treated as if they were not programs at all until the framework for the other architecture was installed on the system. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: cross-compiling with libtool
On Wed, 13 May 2015, Lane wrote: arm-blues-linux-gnueabi-libtool: install: chmod 644 /opt/blues/lib/libbl_parsers.a arm-blues-linux-gnueabi-libtool: install: arm-blues-linux-gnueabi-ranlib /opt/blues/lib/libbl_parsers.a ../../../arm-blues-linux-gnueabi-libtool: line 1104: arm-blues-linux-gnueabi-ranlib: command not found Makefile:395: recipe for target 'install-libLTLIBRARIES' failed Any thoughts on how to proceed? 1. Assuming that you want to make progress with your work. 2. Assuming that your other cross-tools are named prefixed with 'arm-blues-linux-gnueabi-'. 3. Assuming that ranlib is not actually necessary. You could change to the directory where the other cross-tools are and do ln -s /bin/true arm-blues-linux-gnueabi-ranlib Altnerately, you could find a correct ranlib binary and make sure that it is named appropriately. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Running an uninstalled executable
On Tue, 12 May 2015, Alberto Luaces wrote: Hello, in an autoconf+automake+libtool C++ project containing only one program, I want to run the executable before installing it. Reading the manual I thought that it could be done with 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? Libtool is supposed to solve this problem automatically for libraries in the build-tree built using libtool, or involved libraries which have a correct associated .la file. It is not uncommon for the .la files that libtool installs to be deleted, or for libraries to be put into a location other than the paths the .la file says they reside. If the installed libraries violate the libtool expectations, then there are only the choices of building the software with a hard-coded run-path (-RLIBDIR or -Wl,-rpath,/libdir'), or using environment variables like LD_LIBRARY_PATH. As a developer, I find using the run-path to be most reliable/convenient, but this may not be suitable when creating packaged binaries for installation. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool is not wanting to play nicely with cross compiler
On Mon, 6 Apr 2015, Andy Falanga (afalanga) wrote: I'm working on compiling some code for an ARM processor on a Xilinx board. I did not do the work of configuring the cross compiler and so am ignorant about some parts of this process. I recommend reading the Autoconf manual as pertains to cross-compilation. How are your cross-tools named? Tool naming is important. What are the arguments that you passed to configure? I've finally gotten my configure script to complete and was running the main compilation when I ran into this error: libtool: link: warning: `/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems to be moved libtool: link: warning: `/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems to be moved libtool: link: warning: `/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems to be moved /bin/grep: /usr/lib/libstdc++.la: No such file or directory /bin/sed: can't read /usr/lib/libstdc++.la: No such file or directory libtool: link: `/usr/lib/libstdc++.la' is not a valid libtool archive The .la files are just text files which libtool uses to remember build information to be re-used when using the associated library. The complaint about being moved is because these files are located in a different place than when they were originally installed (by whoever built/packaged them). The .la file contains paths which are not correct for your current library installation. libtool is pointed in the right direction because the file libstdc++.la, in the directory indicated, is the one it should be using for cross compilation. However, the file contains this: libdir='/usr/lib' I know this is the source of the warning, but why would I be getting the warning? If my understanding is correct, the stuff in this directory is made into the image what it placed onto the embedded system. Thus, when that OS is running, libstdc++.la would actually be in '/usr/lib'. However, it seems that libtool decides that it will look in '/uar/lib' for libstdc++.la anyway and ignore that it found the file where it was told it would. Well, just as is indicated, there isn't a libstdc++.la file in '/usr/lib'. How do I make libtool happy with the la archive (is that what they're called) that it should be using? Libtool does work for cross-compilation mode but tools must be named appropriately, autoconf arguments must be supplied appropriately, and the build toolchain needs to be smart enough to use its own sysroot for cross-compilation rather than accidentally using host system libraries/headers. Not every configure script is appropriately prepared for cross-compilation since some tests are impossible when cross-compiling and so appropriate defaults need to be supplied. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: argument list too long error
On Wed, 25 Mar 2015, Vincent Torri wrote: Is this log file sufficient ? Yes, because it shows that the problematic arguments were passed to libtool's command line, and not produced internally by libtool. Perhaps the repetitions were produced by a improperly constructed configure script, Makefile, or somehow induced into the execution environment? It seems that CPPFLAGS was constructed improperly, adding similar stuff over and over rather than just once. Bob Vincent Torri On Wed, Mar 25, 2015 at 8:39 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Wed, 25 Mar 2015, Vincent Torri wrote: also it seems that on Linux, it's not the case (no such long list of arguments), while on Windows, it is. So maybe a problem in the Windows port of libtool The only way to know this is if we could see the arguments which were passed to libtool, but you did not provide this to us. Are the duplicate arguments passed to libtool? Windows has a vastly smaller command line limit than Linux does, and the Windows command-line limit is combined with environment variable space so more environment variables decreases the command-line length limit. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ https://lists.gnu.org/mailman/listinfo/libtool
Re: argument list too long error
On Wed, 25 Mar 2015, Vincent Torri wrote: hello, In a project i'm following, i've seen that bug report: https://phab.enlightenment.org/T2225 The build system pass a huge number of identical options and libtool does not try to remove them is it a problem with libtool (that is, libtool should indeed remove such identical options) or in the build system (that is, we should optimize the build system so that non identical options are passed) ? The URL you posted requires a login. Are you able to provide an example or summarize the problematic identical options here? Libtool is not intended to be an optimizer. If it drops or re-orders options (as happens sometimes), then the build may fail. A list of arguments which is already too long when libtool is invoked is already a lost cause. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: argument list too long error
On Wed, 25 Mar 2015, Vincent Torri wrote: also it seems that on Linux, it's not the case (no such long list of arguments), while on Windows, it is. So maybe a problem in the Windows port of libtool The only way to know this is if we could see the arguments which were passed to libtool, but you did not provide this to us. Are the duplicate arguments passed to libtool? Windows has a vastly smaller command line limit than Linux does, and the Windows command-line limit is combined with environment variable space so more environment variables decreases the command-line length limit. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: GNU libtool-2.4.6 released [stable]
On Mon, 23 Mar 2015, Christian Rössel wrote: Dear Gary, thanks for libtool-2.4.6! 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. I see the same issue with 2.4.5, but not with 2.4.4 (and earlier). 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. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Bash-specific performance by avoiding sed
On Mon, 9 Mar 2015, Mike Gran wrote: Hello libtool, I don't know if y'all saw this blogpost where a guy pushed the sed regular expression handling into bash-specific regular expressions when bash was available. He claims there's a significant performance improvement because of reduced forking. http://harald.hoyer.xyz/2015/03/05/libtool-getting-rid-of-18-sed-forks/ There is an issue in the libtool bug tracker regarding this. This solution only works with GNU bash. It would be good if volunteers could research to see if there are similar solutions which can work with other common shells (e.g. dash, ksh, zsh). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
On Fri, 6 Feb 2015, Robert Yang wrote: On 02/06/2015 12:12 PM, Bob Friesenhahn wrote: I am not seeing quite the difference between libtool releases that you are although I see a big slowdown starting with 2.4.3. These timings are for optimized builds of GraphicsMagick on a 12-core GNU/Linux system using -j 12: I think that we can't see obviously slowdown by make -jN, but make -j1 will. And bash is much slower than dash, I'm trying to figure out why. It seems like this issue is already corrected in the source tree but you are correct that the issue is much more apparent with -j1. Optimized: 2.4.2 : 3:43.43 2.4.5 : 4:33.11 Non-Optimized: 2.4.2 : 1:21.21 2.4.5 : 2:05.48 We need a test case which is executed before every major release to make sure that a performance regression has not been introduced. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
I am not seeing quite the difference between libtool releases that you are although I see a big slowdown starting with 2.4.3. These timings are for optimized builds of GraphicsMagick on a 12-core GNU/Linux system using -j 12: 2.4.2 : 23.613 2.4.3 : 31.697 2.4.4 : 28.236 2.4.5 : 28.514 And here are timings for a non-optimize (-O0) compile with no debug symbols: 2.4.2 : 8.629 2.4.3 : 13.216 2.4.4 : 13.012 2.4.5 : 13.281 I see similar slowdowns on an Illumos-based system, so it is not specific to GNU/Linux. It is curious that there is more impact for the optimized builds. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
On Wed, 4 Feb 2015, Robert Yang wrote: When reporting a bug, please describe a test case to reproduce it and include the following information: host-triplet: $host shell: $SHELL compiler: $LTCC compiler flags: $LTCFLAGS linker: $LD (gnu? $with_gnu_ld) version:$progname (GNU libtool) 2.4.5 automake: `($AUTOMAKE --version) 2/dev/null |$SED 1q` autoconf: `($AUTOCONF --version) 2/dev/null |$SED 1q` Perhaps libtool is accidentially executing 'automake --version' and 'autoconf --version' every time it is executed? That would certainly lead to a huge slowdown. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
On Tue, 3 Feb 2015, Robert Yang wrote: Sorry, I was wrong, tt seems that libtoolize is not the key, but libtool, when compile cairo-1.12.18: libtool 2.4.2 libtool 2.4.5 configure: 31s 32s compile:54s 64s The libtool 2.4.5 costs 10 more seconds. I'm debugging on it, any suggestion is appreciated. The build slowdown must not be my imagination then. I had attributed the slowdown to other factors. Recently I noticed that build times for my own project were significantly longer than I remember. Previously libtool was heavily optimized to reduce the number of forks (execution of child process). This optimization should still be present in 2.4.2. Any additional forks will result in a slower build. It is not necessary to libtoolize a package in order to test its build performance with different libtool versions. You can specify LIBTOOL in the environment (see the Makefiles) such that it points to the uninstalled libtool in a libtool build tree. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
On Mon, 2 Feb 2015, Robert Yang wrote: Hello libtool, It seems that libtool (2.4.4) has increased the packages build time, after a rough investigation, it maybe because new libtoolize needs run a m4 command: Did you time 'libtoolize' and compare the timings with 2.4.4 to the release you were using before? Libtoolize is not normally considered to be part of package build time since packages usually already come 'libtoolized' (using some random version of libtool). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: lt_dlopen no return
On Mon, 15 Dec 2014, Orc Erc wrote: Hi All, When i called the lt_dlopen function, it sticks. There is no return from that function. Where do i look? Run your program under a debugger such as GDB. While it is stuck, do CONTROL-C on the keyboard and then then enter 'bt' at the GDB command-line. This should show where it is stuck. An alternative is to make sure that core dumps are properly enabled and then do kill -QUIT pid where pid is the process ID of the stuck process. You should then get a core dump of the program that you can investigate using a debugger. If you need more help here, then you would need to tell us the libtool version you are using, and the operating system you are running it on. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec
On Wed, 5 Mar 2014, Orion Poplawski wrote: Use ldconfig to generate sys_lib_dlsearch_path_spec so that internal library search paths as well as all /etc/ld.so.conf and /etc/ld.so.conf.d/*.conf entries are present. It seems unwise to use ldconfig output as authoritative information since ldconfig might produce output based on local system configuration (e.g. additional search directories) rather than based on the standard for that OS release/distribution. The built binaries might then not run if put on another system from the same OS release/distribution. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
