Re: Several questions about libtool
Russ Allbery skrev 2012-01-07 03:13: Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: Libtool's mode of operation works with static builds and on systems where all libraries have to be supplied at link time. Of which there are very few still in existence in terms of widespread use, since most systems now use ELF or (like Mac OS X) some other object format that doesn't require this. Solaris is definitely not one of them. I believe you may still need this on such platforms as AIX or HP-UX that use a much different object format, but I'm not at all certain of that; it's been years since I've used them. You are somehow forgetting Windows, probably the most widespread system of them all. On Windows, you have to specify all libraries at link time and Libtool helps with that. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Several questions about libtool
Peter Rosin p...@lysator.liu.se writes: Russ Allbery skrev 2012-01-07 03:13: Of which there are very few still in existence in terms of widespread use, since most systems now use ELF or (like Mac OS X) some other object format that doesn't require this. Solaris is definitely not one of them. I believe you may still need this on such platforms as AIX or HP-UX that use a much different object format, but I'm not at all certain of that; it's been years since I've used them. You are somehow forgetting Windows, probably the most widespread system of them all. On Windows, you have to specify all libraries at link time and Libtool helps with that. Indeed, I did forget Windows. (Although while it's the most widespread system of them all, it's a small fraction of the platforms on which people use Libtool on a day-to-day basis.) I wouldn't argue for breaking Libtool's ability to handle such platforms, or for that matter old UNIX platforms that don't support transitive resolution of shared library dependencies. But I think Libtool needs some mechanism to correctly support platforms where adding spurious NEEDED ELF metadata is wrong and causes serious issues for distributions. The pkg-config approach seems to work reasonably well in practice. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: dlopen, DESTDIR, library dependencies and cannot install error
On Fri, 6 Jan 2012, Diab Jerius wrote: and the installation is performed via make AM_MAKEFLAGS=DESTDIR=/proj/axaf/simul/pkgs prefix=/lua_udunits2-0.1.2_01 exec_prefix=/lua_udunits2-0.1.2_01/x86_64-linux_debian-5.0 install Why do you use make AM_MAKEFLAGS=DESTDIR=... rather than make DESTDIR=... ? Where is such use of AM_MAKEFLAGS documented? This results in a libtool invocation of /bin/sh ../libtool --mode=install /usr/bin/install -c udunits2.la '/proj/axaf/simul/pkgs/lua_udunits2-0.1.2_01/x86_64-linux_debian-5.0/lib/lua/5.1' which fails with: libtool: install: error: cannot install `udunits2.la' to a directory not ending in /proj/axaf/simul/x86_64-linux_debian-5.0/lib/lua/5.1 I believe the problem is that I'm linking the dlopen'able module against a library which hasn't yet been installed (as it is part of the distribution). I haven't been able to distill anything from the libtool documentation which would touches upon this issue. It seems more like libtool is refusing to install the .la file to a directory other than where it is supposed to reside. If you look inside the .la file, you will see that it even records the directory where it is supposed to reside. Is this the correct diagnosis and is there a fix? I suggest trying the 'make DESTDIR' approach instead. 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: Several questions about libtool
On Sat, 7 Jan 2012, Russ Allbery wrote: Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: I think that it is wrong to solely blame libtool for this state of affairs. In order for a project to work properly on non-ELF systems, or where installed shared libraries have abbreviated/truncated ELF implicit dependencies, or where static libraries are involved, the project needs to add all dependencies to LIBS during the configure run. pkg-config is an excellent example of an alternative way of handling this that does not have this problem, and it includes Autoconf support. What do you mean by it includes Autoconf support. Do you mean that it provides an Autoconf macro which makes pkg-config easier to use? Regardless, Autoconf's configure will still make subsequent decisions based on trial and error (by running the compiler and linker). One interesting possible solution to this problem would be to eliminate Libtool *.la files in favor of pkg-config or something similar, rather than continuing to maintain two different mechanisms for doing largely the same thing. They may seem like they do the same thing but perhaps they do 20-30% of the same thing (e.g. dependency info). The .la files used in the build tree are very much needed since it is unlikely that builds will work at all without them (and libtool needs them). I do agree that a tool can help solve these issues. The linker itself is in the best position to know which library dependencies are really needed and to skip those which are not. It turns out that this is harder than it looks. --as-needed causes obscure failures in places where the dependency really is needed although the linker can't figure that out. I suspected as much. The pkg-config solution allows the maintainer of the library to declare the necessary behavior for both cases: working transitive dependency resolution, and situations where this cannot be relied upon. The build system then chooses based on the situation. Pkg-config is optional software which only really works when it is properly cared for and fed correctly. Autotools (as currently defined) can not depend on it. However, we need to determine if there is some way that libtool can work better for modern ELF platforms using only shared libraries while still supporting portability requirements, and use with static libraries. The obvious solution is that there should be a mode in which libtool does not apply any .la dependency libraries from an installed .la file unless they are known to be static libraries, or static libraries are otherwise involved. The various .la files listed in dependency_libs would need to be inspected to see if a shared or static library would be used. If any static library would be used, then all of the library dependencies would still need to be applied out of fear that the static library depends on a symbol in a shared library. Since GNU/Linux disributions have taken the approach of stripping all .la files from the distribution, the above approach becomes more risky to implement. 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: Several questions about libtool
On Sat, 7 Jan 2012, Russ Allbery wrote: Regardless, Autoconf's configure will still make subsequent decisions based on trial and error (by running the compiler and linker). Do you mean for detecting other libraries? Only for libraries without pkg-config support. You of course can't solve the whole problem For detecting library features such as the availabilty of functions. Over the years, Autoconf principles have not changed much. It could have usefully absorbed knowledge of libtool and its installed .la files (but it did not). Pkg-config is optional software which only really works when it is properly cared for and fed correctly. The same is true of Libtool. :) Except that libtool is already embedded (in one vintage or another) in the source code of perhaps 5000 (???) different packages. This makes the pace of change somewhat glacial. My impression is that you don't want to try to do this with magic, because the magic will occasionally be wrong. That's the advantage of the pkg-config method. It lets the library maintainer, who actually knows what's going on, specify the desired behavior. The distribution library maintainer only knows what is going on from within his own limited sphere of influence. Once the package is finally installed on a user's system, there is no telling what might happen after that. The user might be the developer of the library that the distribution library maintainer prepares as a binary package. Believe it or not, there are still people who download source packages and install software by building it from source code, or who develop new software from scratch, or by modifying existing source code. Due to this, the pristine environment that the GNU/Linux distribution package maintainer is aware of is not necessarily representative of the user's system, or the user's intentions. Given the principles of free software, we should not assume that software users will only get the software via carefully-prepared and managed binary packages provided by an OS distribution. We should encourage people to actively edit source code and develop more free software or else the free software movement will eventually terminate by quenching the innovation which spawned it. Free software should not fall victim to its own success. Autotools needs to satisfy the requirements of completely different types of users. This means that it still needs to work (best-effort) if pkg-config offers up some wrong (perhaps stale) information, or if the user has several independent (or complimentary) pkg-config installations on his system. It also needs to work if pkg-config is not available at all. You are correct that I don't put much faith in magic. :-) I feel that I may have gotten a bit off track here, but it should be clear that libtool needs to err towards the most reliable mechanisms by default (the software should build and work by default if at all possible) but also provide the features that distribution maintainers need. 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: ac_run_ifelse and libtool
And another ping! Werner I've found this interesting mail: http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html Interestingly, there was no comment at all. So my question: Is this the `right' approach? Will libtool provide something similar? ___ https://lists.gnu.org/mailman/listinfo/libtool
