Re: What happened to libtool transitive DSOs?
In regard to: Re: What happened to libtool transitive DSOs?, Bob...: 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. Sorry to jump into this discussion late, but I wanted to point out that at least RHEL seems to be moving away from using implicit library dependencies. In the RHEL 7.5 (current latest) release notes, chapter 53, on deprecated functionality: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality there's this note: Symbols from libraries linked as dependencies no longer resolved by ld Previously, the ld linker resolved any symbols present in any linked library, even if some libraries were linked only implicitly as dependencies of other libraries. This allowed developers to use symbols from the implicitly linked libraries in application code and omit explicitly specifying these libraries for linking. For security reasons, ld has been changed to not resolve references to symbols in libraries linked implicitly as dependencies. As a result, linking with ld fails when application code attempts to use symbols from libraries not declared for linking and linked only implicitly as dependencies. To use symbols from libraries linked as dependencies, developers must explicitly link against these libraries as well. To restore the previous behavior of ld, use the -copy-dt-needed-entries command-line option. (BZ#1292230) - end excerpt from RHEL release notes Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-2.4.2.418 released [alpha]
Libtoolers! The Libtool Team is pleased to announce the release of libtool 2.4.2.418. This is a preliminary alpha release to begin platform testing in preparation for the next stable release. I built 2.4.2.418 on x86_64-pc-solaris2.11 (OpenIndiana 151a8) with the Oracle Studio 12.3 toolchain. There was one unexpected failure in the new test suite: 21: quote shell meta-characters in filenamesFAILED (libtool.at:120) If I re-run the test-suite with --verbose, test #21 shows: 21. libtool.at:60: testing quote shell meta-characters in filenames ... ./libtool.at:102: $LIBTOOL -n --mode=$mode $preargs $preflag$flag:test $postargs stdout: libtool: compile: cc -c -DVAR=:test foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=:test foo.c -o foo.o /dev/null 21 ./libtool.at:106: grep $mode:.*$match_preflag$flag:test stdout stdout: libtool: compile: cc -c -DVAR=:test foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=:test foo.c -o foo.o /dev/null 21 ./libtool.at:116: $LIBTOOL -n --mode=$mode $preargs $preflag$flag\\:test\\ $postargs stdout: libtool: compile: cc -c -DVAR=\\:test\\ foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=\\:test\\ foo.c -o foo.o /dev/null 21 ./libtool.at:120: grep $mode:.*$match_preflag'\?'$flag:test'\? ' stdout stdout: ./libtool.at:120: exit code was 1, expected 0 21. libtool.at:60: FAILED (libtool.at:120) Let me know what other useful information I can provide. There's a patch after my signature that alters the README to provide the actual name of the log file from the test suite. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 --- libtool-2.4.2.418.orig/README 2013-10-26 19:02:00.0 -0500 +++ libtool-2.4.2.418/README2013-11-05 16:16:33.243527395 -0600 @@ -113,7 +113,7 @@ to send the verbose output of the FAILing group, along with the information from the end of '$(top_builddir)/libtool --help' to the bug report mailing list, bug-libt...@gnu.org with a subject line that -includes the string '[TEST FAILURE]'. The file test-suite.log contains +includes the string '[TEST FAILURE]'. The file testsuite.log contains the verbose output from all failed tests. In order to enable debug shell tracing, you can set VERBOSE=debug when ___ https://lists.gnu.org/mailman/listinfo/libtool
solaris recording name conflict when building newer versions of system libraries
All- I'm getting the recording name conflict error from the Solaris linker, as invoked by libtool 2.4.2, and I'm hoping someone can provide some suggestions for how to work around this issue. I've been building software on Solaris for years, including software that uses libtool. I remember what it was like before libtool, so I'm thankful that libtool exists, even when current libtool is doing something I dislike. :-) I'm starting to build some software on OpenIndiana, which is one of the distributions that came out of the former OpenSolaris initiative. I'm using Oracle's Studio 12.3 compiler suite and the standard linker (not GNU ld). Unlike e.g. Solaris 10, OpenIndiana comes with quite a lot of opensource software installed under /usr. This is causing some build problems for me that I generally did not encounter under previous versions of Solaris. I'm trying to build newer versions of some of packages, for installation under /local, but I'm encountering a problem at link time because the linker detects that there's already a shared object in the system directory with the same soname. In this particular case, I'm trying to build a newer version of cairo, but during the build, tools that should link with the newly-built libcairo fail: libtool: link: cc -xO4 -xipo=2 -D_REENTRANT -D_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -I/local/gnu/include/gio-unix-2.0/ -I/local/gnu/include/glib-2.0 -I/local/gnu/lib/64/glib-2.0/include -I/local/include/pixman-1 -I/usr/include/librsvg-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/amd64/gtk-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng14 -Xa -xO4 -xipo=2 -xstrconst -KPIC -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -I/local/include -D_POSIX_PTHREAD_SEMANTICS -o .libs/any2ppm any2ppm-any2ppm.o -L/local/lib/64 -L/local/gnu/lib/64 ../util/cairo-script/.libs/libcairo-script-interpreter.so -L/usr/local/lib/64 -L/usr/lib/amd64 /local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so ../src/.libs/libcairo.so -ldl -lGL -lrsvg-2 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 /local/gnu/lib/64/libgio-2.0.so -lsocket -lresolv /local/gnu/lib/64/libgmodule-2.! 0.so -lXext -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lcairo /local/gnu/lib/64/libgobject-2.0.so /local/gnu/lib/64/libgthread-2.0.so -lffi /local/gnu/lib/64/libglib-2.0.so -lpthread -lthread /local/gnu/lib/64/libintl.so -lc /local/lib/64/libpixman-1.so -lfontconfig -lexpat -lfreetype -lbz2 -lpng14 -lz -lXrender -lX11 -lrt -lm -mt -R/local/lib/64 -R/local/gnu/lib/64 -R/usr/lib/amd64 ld: warning: file ../src/.libs/libcairo.so: linked to /local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so: attempted multiple inclusion of file ld: fatal: recording name conflict: file '/local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so' and file '/usr/lib/amd64/libcairo.so' provide identical dependency names: libcairo.so.2 (possible multiple inclusion of the same file) ld: fatal: file processing errors. No output written to /dev/null /opt/SUNWspro/prod/bin/ipo: Error inside /usr/ccs/bin/ld cc: ipo failed for .libs/any2ppm gmake[4]: *** [any2ppm] Error 2 Anyone have any suggestions for how I work around this? Unfortunately, many of the OpenIndiana system packages don't split into runtime and devel packages, so where it would be possible to work around something like this on other platforms by removing the system's devel package, here I can't. The package '/library/desktop/cairo' includes all of cairo, including the parts that other platforms would split into a separate devel package. I can get the link to proceed if I manually copy what libtool is doing, and then change /local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so ../src/.libs/libcairo.so to -L/local/src/RPM/BUILD/cairo-1.12.14/src/.libs -lcairo The question is, is there any way to get libtool to do that automatically on Solaris? If I need to hack my local copy of libtool to do that (and then re-libtoolize projects that run into this issue, so that they're using my hacked libtool), can anyone point me at places in the libtool source where I should look to make this change? Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR
URL: http://savannah.gnu.org/support/?107416 Summary: relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR Project: GNU Libtool Submitted by: enchanter Submitted on: Fri 02 Jul 2010 02:29:31 PM CDT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None ___ Details: This issue affects all versions of libtool from 2.2.10 going back to the initial versions that added support for DESTDIR installs. Consider a package package-1.0, which includes two libraries liba and libb. liba has a function named a_1, and libb requires this function and is linked against liba. package-1.0 gets installed on a system and everyone is happy. Now package-2.0 comes out. liba now has a new function a_2, and libb now uses both a_1 and a_2. When compiling package-2.0, libb will correctly link against the liba that's included in package-2.0. If you just make install, libb will be correctly relinked, because liba will get installed in the final location first. HOWEVER, if you do a DESTDIR install, the relink step for libb will fail, because libtool doesn't prepend the DESTDIR library directory to the library search path, so when libb is relinked, it finds the liba from package-1.0 that's already installed on the system. Since the 1.0 version of liba doesn't have function a_2, the relink fails. This issue has been reported on the libtool mailing list several times, e.g. http://lists.gnu.org/archive/html/libtool/2003-02/msg00098.html http://lists.gnu.org/archive/html/libtool/2003-05/msg00022.html http://lists.gnu.org/archive/html/libtool/2009-11/msg00010.html http://lists.gnu.org/archive/html/libtool/2002-11/msg00112.html I can find more instances in the mailing lists if necessary, but you get the point. It's affected a lot of people, and it's a real hassle for people that do software packaging with something like RPM or apt. ___ Reply to this item at: http://savannah.gnu.org/support/?107416 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR
In regard to: Re: [sr #107416] relink with a DESTDIR install mistakenly...: On Fri, 2 Jul 2010, Tim Mooney wrote: This issue affects all versions of libtool from 2.2.10 going back to the initial versions that added support for DESTDIR installs. This does not seem to be a libtool bug: % grep DESTDIR libtool % Since libtool does not handle DESTDIR, then it must be the responsibility of a higher-level, such as the makefile. If you are using Automake, maybe there is a deficiency in your project's Makefile.am, or even Automake itself. There is a known Automake bug in that libraries need to be listed in a particular order so that old installed libraries won't be used by mistake. Take a look at a few of the mailing list threads I quoted, especially the one from Charles Wilson. Then check out the -inst-prefix-dir code in libtool. This is where the DESTDIR support is. Tim -- Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Installed libs wrongly used on 64-bit Linux?
In regard to: Installed libs wrongly used on 64-bit Linux?, Bob Friesenhahn...: Starting yesterday I am hearing of GraphicsMagick 1.3.3 users who built from source code and found that the installed loadable modules are depending on a previously installed lesser-version GraphicsMagick library rather than the one in the build tree. Both of the reporting users are using a 64-bit Linux (Gentoo and CentOS) which supports both 32/64 bit libraries. The GraphicsMagick build was apparently a 32 bit build. GraphicsMagick 1.3.3 uses libtool 2.2.6. One user reported that building and installing twice solves the problem. I've run into the exact same problem with various libtool versions (both 1.5.x and 2.2.x) over the years, for several different packages. I do most of my building on Solaris 10, and generally build only 64 bit. I can also confirm that doing an install of the package and then another rebuild addresses the problem. In my case, I'm 100% certain that the problem relates to the fact that I'm using a build root while packaging the software (RPM). Are both of your users doing the same? I'm almost certain the problem is that there's a /usr/local/lib/64/libfoo.la from version 1.0 of package bar, and when I'm building bar version 1.1 and it builds version 1.1 of libfoo.la, during the relink phase of make install, bar is being linked against the version 1.0 libfoo.la that's in /usr/local/lib/64, rather than the version 1.1 libfoo.la that was just installed in e.g. /tmp/build/bar/usr/local/lib/64. Tim -- Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Multiple -rpaths
In regard to: Re: Multiple -rpaths, Ralf Wildenhues said (at 8:21am on Nov...: * Jan Engelhardt wrote on Tue, Nov 04, 2008 at 07:58:36AM CET: So I guess the reasons why distros remove the .la files is because they are within the default search paths. Yes; and because some versions of libtool did the wrong thing wrt. multi-ABI systems like x86_64. (BTW if there are still bugs in this area, we'd appreciate reports.) I thought the reason that distros remove .la files is because some distro vendors feel that libtool often establishes direct link dependencies that aren't needed, and those direct dependencies can cause headaches during upgrades? Tim -- Tim Mooney [EMAIL PROTECTED] Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool C++ link bug with -lm functions with Sun Workshop compiler
[1]: Leaving directory `/local/src/RPM/BUILD/aspell-0.60.5' gmake: *** [all-recursive] Error 1 By visual inspection, it doesn't look like the relevant code in libtool.m4 that automatically adds `-library=Cstd -library=Crun' has changed in any significant manner since 1.5.2X. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164___ http://lists.gnu.org/mailman/listinfo/libtool
libtool C++ link bug with -lm functions with Sun Workshop compiler
I think I have discovered a bug in libtool's link behavior with the Sun Workshop C++ compiler when creating a C++ library that requires libm. I observed it on x86_64-sun-solaris2.10, but it may also affect the Workshop C++ compiler on Linux too. I found it when trying to build GNU aspell 0.60.5. If you have a configure.ac that calls AC_LANG([C++]), any subsequent AC_CHECK_FUNCS will result in a link that uses the C++ compiler. Because the C++ compiler initiates the link, it automatically adds some libraries to the final call to ld. Which libraries it adds depends on what flags CC was passed (arguments like -library=stlport4 change what C++ libraries are automatically added). The C++ compiler appears to always add `-lm -lc' after the C++ libraries, though. That means that doing something like AC_INIT(lttest, 0.60.5) AC_CONFIG_SRCDIR(configure.ac) AC_PROG_CXX AC_LANG([C++]) AC_CHECK_FUNCS(sqrt) AC_OUTPUT will always detect sqrt(), because the C++ compiler added `-lm -lc' behind the scenes. When libtool is called to generate a C++ library on Solaris, it doesn't add -lm, though. It only adds -lc. That will result in link failures if functions like sqrt(), floor(), etc. from libm are used by the C++ library. Is the correct fix to just add -lm to the postdeps for Solaris and Linux when using the Workshop compiler, or is there some other method that should be used? I'm talking about changing all instances of _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' to _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun -lm' Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool C++ link bug with -lm functions with Sun Workshop compiler
In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...: On Wed, 19 Mar 2008, Tim Mooney wrote: That means that doing something like AC_INIT(lttest, 0.60.5) AC_CONFIG_SRCDIR(configure.ac) AC_PROG_CXX AC_LANG([C++]) AC_CHECK_FUNCS(sqrt) AC_OUTPUT will always detect sqrt(), because the C++ compiler added `-lm -lc' behind the scenes. Then it seems like you did something wrong and libtool is not to blame. I don't think so. I discovered the problem with GNU aspell. The snippet I show above is just to illustrate the problem. Perhaps it is not best to run most of your configure script using the C++ compiler. Only run the C++ compiler to test C++ things. I don't disagree, but at the same time, if everything a project is going to build is going to be compiled by the C++ compiler, doesn't it make sense for the C++ compiler to actually do the tests? If it's the C++ compiler that needs to see the prototype for sqrt(), and it's the C++ compiler that's going to initiate the link, it doesn't make a lot of sense for the tests to be conducted by the C compiler. That's hardly a good test; there are several reasons why what the C compiler can see for prototypes or test link might differ from what the C++ compiler would. There are projects out there, beyond GNU aspell, that are using the C++ compiler for many of the configure tests. Are they all wrong to do so? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking a C program with a C++ library on Solaris
In regard to: Re: linking a C program with a C++ library on Solaris, Ralf...: Hello Bob, Tim, * Bob Friesenhahn wrote on Tue, Feb 26, 2008 at 03:11:44AM CET: On Mon, 25 Feb 2008, Tim Mooney wrote: I don't see anything in 2.1b's info files or README or NEWS for updating a project from 1.5.x to 2.2. I assume that means that there's nothing a project maintainer needs to do other than to re-libtoolize his or her project? I believe that backward compatability has been mostly respected. Yes, but just running libtoolize has never been enough. Absolutely -- I guess I was just implying the aclocal run too, though I should have been more explicit. My main question was whether any new macros needed to be called, or old ones needed to change how they're called, and it looks like that's generally not needed, which is great news. Running aclocal (with Libtool 2.2's macro files visible to aclocal) to get the new macro definitions is also needed; autoreconf -vf takes care of both. As a subsequent poster has mentioned, I've also noticed that autoreconf typically only runs aclocal *before* libtoolize, which struck me as odd when I noticed it. I'm not saying that autoreconf's behavior is broken, since I've only used it a few times and have never noticed a problem because of this unexpected order in which it runs the commands. I was just surprised at the order it has used on the few occasions that I've used it. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
linking a C program with a C++ library on Solaris
I've been building and packaging a lot of software in the past couple weeks on my x86_64-sun-solaris2.10 workstation. I've been using the Sun Workshop 12 C and C++ compilers for the builds. I've run into several situations in the past week where I'm building a package that's mainly written in C (nautilus, tracker, faac, et. al.) that wants to link with a C++ library (exempi, mpeg4ip). In all the permutations I've encountered so far, both the C++ library and the C package are using libtool, and I've always updated both to use 1.5.26. On Solaris, if you are linking against any C++ objects, you must use the C++ compiler to link. I don't know if that's common to other platforms or not, as I don't have access to the plethora of UNIX platforms I used to. In any case, the packages I've encountered don't seem to expect that, so the (libtool) link stage for the C project doesn't know to use C++, and the link fails. Is this something that libtool could be (should be?) handling automatically? Even if it can't be handled automatically, is there something that libtool could be doing to help make it easier for packages that are primarily C (but link against C++ libraries/objects) to know that they need to switch to C++ for linking in their C project? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 1:05pm on...: Sorry, I forgot the last point: As a result, we need a way to have Libtool not link in any STL library at all. How can we do this? Thanks for clarifying what you're trying to accomplish. What happens if you use CXXFLAGS=-library=%none -library=no%libC Does libtool still thwart your efforts? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Sun Studio: STL libraries, Dan Lacher said (at 12:04pm on Feb...: In trying to resolve a C++ issue within Open MPI we've run into an issue with Libtool automatically linking in Cstd. Because Sun Studio supports two different types of C++ STL libraries (Cstl and stlport4) we needed to remove Open MPI's reliance on STL functions so applications being compiled with Sun Studio could use either version of STL libraries (note once you link with one you cannot use the other STL library). I just ran into the opposite of this problem yesterday. The short answer: you're using a version of libtool that's pretty old. This issue was fixed in 2006. Upgrade your libtool, and the problem will go away. Now, libtool doesn't force either Cstd or Crun into the libraries, which means that if you use -library=stlport4 as part of CXXFLAGS, you probably also need -library=Crun since that won't automatically be added. I personally think that libtool should still be adding -lCrun automatically, as it does for -lc, since -lCrun is compatible with stlport4, but since there's a workaround, it's no big deal. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:05pm...:
I still maintain that it would be OK to have libtool automatically add
`-library=Crun', since that is generally needed whether you're using
-library=stlport4 or -library=Cstd, but it's OK to not include that. We
just need to make sure the correct usage is documented somewhere.
If it's not currently documented (I don't know, I haven't checked the 2.x
series), I would be willing to write a little blurb for the info files
or some other spot, if people want.
Something in notes.texi?
How about this:
--- libtool-2.1b.orig/doc/notes.texi2008-01-26 00:21:22.0 -0600
+++ libtool-2.1b/doc/notes.texi 2008-02-06 17:32:43.89529 -0600
@@ -77,4 +77,27 @@
@code{lt_cv_sys_lib_dlsearch_path_spec} respectively to the correct search
paths.
[EMAIL PROTECTED]
+When using the C++ compiler from the Sun Workshop (formerly Forte)
+development environment on either Solaris or Linux, libtool will use
[EMAIL PROTECTED] as the linker, and will not automatically link with either
[EMAIL PROTECTED] or @file{libCrun}. This is because recent versions of
+Sun Workshop (11 and 12, as of this writing) have the option of using
[EMAIL PROTECTED] or @file{stlport4_dbg}, and those libraries are
+incompatible with @file{libCstd}.
+
+The correct method to link with the additional libraries that your project
+needs is to include each library in the @code{CXXFLAGS} when configuring your
+project. For example,
+
[EMAIL PROTECTED]
+ CXXFLAGS='-library=stlport4 -library=Crun'
[EMAIL PROTECTED] example
+
+or
+
[EMAIL PROTECTED]
+ CXXFLAGS='-library=Cstd -library=Crun'
[EMAIL PROTECTED] example
+
@end itemize
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:25pm...: Peter O'Gorman wrote: Tim Mooney wrote: In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 4:57pm on...: Even with what Tim has pointed out I am seeing the contrary with the following: o Open MPI src base o Sun Studio 12 o libtool 2.1b (just downloaded the latest) After autogen has finished the aclocal.m4 ends up with -library=Cstd -library=Crun both. So that is what is used in the creation of the libmpi_cxx.so.0 Looks like Albert's change from 2006-08-01 only went onto the 1.5 branch, and not HEAD. It should be on both branches. Thanks, I will find it and put it on HEAD. Um, libltdl/m4/libtool.m4 has this check in _LT_SYS_HIDDEN_LIBDEPS for tag CXX: solaris*) case $cc_basename in CC*) # The more standards-conforming stlport4 library is # incompatible with the Cstd library. Avoid specifying # it if it's in CXXFLAGS. Ignore libCrun as # -library=stlport4 depends on it. case $CXX $CXXFLAGS in * -library=stlport4 *) solaris_use_stlport4=yes ;; esac # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. if test $solaris_use_stlport4 != yes; then _LT_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' fi ;; esac ;; So color me confused. Me too. Note that the case could be improved, because the same logic should apply if -library=stlport4_dbg is present as well. Tim, you say we still need to have -library=Crun for the stlport4 case? More than likely, yes. The stlport4 incompatibility is with libCstd, not libCrun. It looks like it was not added only because the stlport4 already depends on it (I guess from ldd output?). So there should be no harm in adding it explicitly. But if it shouldn't be needed, it might be nice to leave it off. I just checked, and libstlport4 is indeed linked to libCrun, so it shouldn't be needed explicitly. I think I should repeat my test, and make sure I'm on the right track. Part of the problem was that I was building a project with a very old version of libtool, and although I upgraded libtool to 1.5.26, I might be remembering how things were behaving with the old libtool. I'll rebuild the project and see if I get the same results. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Tim Mooney said (at 6:05pm on...: In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:25pm...: Tim, you say we still need to have -library=Crun for the stlport4 case? More than likely, yes. The stlport4 incompatibility is with libCstd, not libCrun. I just tested with libtool 1.5.26: /bin/bash ../libtool --tag=CXX --mode=link CC -xO2 -library=stlport4 -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -no-undefined -version-info 6:0:5 -L/local/lib/64 -L/local/gnu/lib/64 -o libtag.la -rpath /local/lib/64 tag.lo tagunion.lo fileref.lo audioproperties.lo ./mpeg/libmpeg.la ./ogg/libogg.la ./flac/libflac.la ./mpc/libmpc.la ./ape/libape.la ./toolkit/libtoolkit.la ./wavpack/libwavpack.la ./speex/libspeex.la ./trueaudio/libtrueaudio.la CC -G -zdefs -hlibtag.so.1 -o .libs/libtag.so.1.5.0 .libs/tag.o .libs/tagunion.o .libs/fileref.o .libs/audioproperties.o -z allextract ./mpeg/.libs/libmpeg.a ./ogg/.libs/libogg.a ./flac/.libs/libflac.a ./mpc/.libs/libmpc.a ./ape/.libs/libape.a ./toolkit/.libs/libtoolkit.a ./wavpack/.libs/libwavpack.a ./speex/.libs/libspeex.a ./trueaudio/.libs/libtrueaudio.a -z defaultextract -L/local/lib/64 -L/local/gnu/lib/64 -lz -library=stlport4 -lc -xtarget=native -m64 -xarch=native Undefined first referenced symbol in file void __Crun::pure_error() .libs/tag.o (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) void*__Crun::simple_down_cast(void*,const __Crun::static_type_info*,const __Crun::static_type_info*) ./mpeg/.libs/libmpeg.a(id3v2tag.o) (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) void __Crun::vector_des(void*,unsigned long,unsigned long,void(*)(void*)) ./mpeg/.libs/libmpeg.a(id3v1genres.o) (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) void*operator new(unsigned long,void*) .libs/fileref.o (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) [additional symbols elided] So, we apparently do need -library=Crun, whether or not -library=Cstd or -library=stlport4 are specified. Here's what ldd reports for libstlport4.so.1: $ldd /opt/SUNWspro/lib/stlport4/amd64/libstlport.so.1 libCrun.so.1 = /usr/lib/64/libCrun.so.1 libm.so.2 = /lib/64/libm.so.2 librt.so.1 =/lib/64/librt.so.1 libc.so.1 = /lib/64/libc.so.1 libaio.so.1 = /lib/64/libaio.so.1 libmd.so.1 =/lib/64/libmd.so.1 I wonder if some of this depends on what version of Workshop one is using? It looks like it was not added only because the stlport4 already depends on it (I guess from ldd output?). So there should be no harm in adding it explicitly. But if it shouldn't be needed, it might be nice to leave it off. I just checked, and libstlport4 is indeed linked to libCrun, so it shouldn't be needed explicitly. I was wrong about that, which is a bit of a surprise (not that I was wrong, I'm used to that ;-) ). I think I should repeat my test, and make sure I'm on the right track. I was on the right track - linking with -library=stlport4 isn't enough to pull in things like void operator delete[](void*), which come from libCrun. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
LT_* equivalent to AC_CHECK_LIB?
This seems like it should be an obvious question, but I'm not finding any obvious answers in either the libtool or autoconf documentation. Is there a libtool-aware equivalent to AC_CHECK_LIB? In other words, if I want to check for foo_amazing_func() in libfoo, and libfoo was built with libtool (and the libfoo.la is hopefully installed on the system), is there an extant macro something like LT_CHECK_LIB(foo,foo_amazing_func) that will try find foo_amazing_func() in libfoo *and* will pull in all the necessary dependencies for libfoo, automatically? The specific case I'm looking at is for a package that wants to check for libneon. Neon (which is a libtool library) might have been linked against OpenSSL (which might require pthread libraries and/or krb5 libraries), and definitely requires one of libxml2 (which might have requirements like zlib, pthread, libm, et. al.) or expat. If I want to check for libneon at configure time, using just AC_CHECK_LIB or AC_SEARCH_LIB will be extremely painful, because even with the fourth argument to either of those macros, I'll still have to write a battery of configure tests to figure out which particular combination of libraries is required to get libneon and its dependencies. If there's a libtool-aware equivalent macro, it would be so much easier. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...: On Mon, 3 Jul 2006, Tim Mooney wrote: This seems like it should be an obvious question, but I'm not finding any obvious answers in either the libtool or autoconf documentation. Is there a libtool-aware equivalent to AC_CHECK_LIB? In other words, if I want to check for foo_amazing_func() in libfoo, and libfoo was built with libtool (and the libfoo.la is hopefully installed on the system), is there an extant macro something like LT_CHECK_LIB(foo,foo_amazing_func) that will try find foo_amazing_func() in libfoo *and* will pull in all the necessary dependencies for libfoo, automatically? I don't believe there is. Autoconf can not depend on libtool, so Autoconf should not provide such a macro, but it certainly makes sense for libtool to provide a LT_CHECK_LIB as you describe. A challenge is that in libtool 2.0, the libtool script is not generated until the end of the configure script run (an `enhancement' in 2.0) so it is not available for use. The macro would need to emulate the operation of libtool since libtool is not available yet. Thanks Bob. It seems like this is one area where pkg-config provides useful functionality that libtool could but doesn't currently. I would prefer to avoid pkg-config, mainly because it introduces another dependency. I haven't looked at the upcoming libtool 2.0 much, and I'm sure there's a very good reason for delaying the generation of libtool until the end of the configure run, but it does appear that it's unfortunate from the aspect of creating a macro like the one we're talking about. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Albert Chin said (at...: The specific case I'm looking at is for a package that wants to check for libneon. Neon (which is a libtool library) might have been linked against OpenSSL (which might require pthread libraries and/or krb5 libraries), and definitely requires one of libxml2 (which might have requirements like zlib, pthread, libm, et. al.) or expat. If I want to check for libneon at configure time, using just AC_CHECK_LIB or AC_SEARCH_LIB will be extremely painful, because even with the fourth argument to either of those macros, I'll still have to write a battery of configure tests to figure out which particular combination of libraries is required to get libneon and its dependencies. If there's a libtool-aware equivalent macro, it would be so much easier. Is libneon a static library? If not, and libneon has the 3rd-party libraries as dependencies, why shouldn't linking with just -lneon work? It is static. The default for libneon is to build static only, so on many systems where the main package would be configured, there would only be a static libneon available. You would certainly know better than I, but I was also under the impression that not all of the common UNIX variants automatically pull in dependant libraries, even when they're listed as dependencies for a shared libneon. I know that works on many (Linux and most/all? ELF-based systems) systems, but I thought a few of the platforms didn't. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...: On Mon, 3 Jul 2006, Tim Mooney wrote: I seem to recall discussion on this list in the past about why distributions were doing that, but I don't recall what any of the reasons were. Has any work (perhaps as part of libtool 2.0) gone into addressing the reason(s) why they were doing that? Operating systems with robust library dependency support don't like the libraries explicitly specifying dependendies on libraries they are not immediately dependent on. Libtool has been specifying the full list of dependencies to the linker, as it finds them in the .la files. Ah yes, thanks for reminding me. That makes sense -- I recall the message about the pain that was going to happen for some distribution that was going to up the soname major for freetype. So to address this, libtool would need to - know how the platform behaves regarding shared library dependencies - in the case of static libraries, continue doing what it's already doing - for shared libraries on platforms where the linker follows library dependencies - when creating a shared library, make sure that it's dependent libraries are recorded (however that's done for a particular platform, probably just linking) by the library when it's created. - when linking against a shared library of this type, detect which libraries are recorded as dependant for the shared library and leave those out of the list of dependency_libs for the shared library. Is that about it? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Ralf Wildenhues said...: * Tim Mooney wrote on Mon, Jul 03, 2006 at 11:17:03PM CEST: So to address this, libtool would need to - know how the platform behaves regarding shared library dependencies - in the case of static libraries, continue doing what it's already doing - for shared libraries on platforms where the linker follows library dependencies - when creating a shared library, make sure that it's dependent libraries are recorded (however that's done for a particular platform, probably just linking) by the library when it's created. - when linking against a shared library of this type, detect which libraries are recorded as dependant for the shared library and leave those out of the list of dependency_libs for the shared library. Is that about it? No. It's much more complicated. That's what I was afraid of. Even the steps I outlined were complex, but I figured someone would have solved it if it was that easy. Thanks for clarifying. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Ralf Wildenhues said...: Has any work (perhaps as part of libtool 2.0) gone into addressing the reason(s) why they were doing that? Hmm. There has been quite some discussion on this and the -patches list. Please use the mail archives to dig it up. Will do. I've suggested an extensive set of testsuite tests (in some Debian bug report) which I would see as a prerequisite to rewriting the deplib search algorithm in ltmain. One point is that, for consistency, the algorithm would need to recursively include all indirect dependencies. If anyone really cares, I can dig up a list of URLs to some important discussion pieces. I also have some half-finished notes, unpublished. What is definitely lacking on my side is something like some months with lots of time... Thanks Ralf. I subscribe to this list but not -patches so I'm much less aware of what goes on there. If I feel the need to dig any deeper on this (pretty doubtful at this point, you and Bob have completely disabused me of the notion that this is something I want to try help solve), I'll do the necessary digging in the archives. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: handling of missing AR
In regard to: Re: handling of missing AR, Ralf Wildenhues said (at 9:33pm...: Hi Brian, * Brian Gough wrote on Wed, Mar 29, 2006 at 09:11:54PM CEST: I've had a libtool-related problem reported with a test release of GNU GSL on a Solaris system with gcc Sun ld, but missing 'ar'. Erm. The user did not have /usr/ccs/bin in $PATH? I've never heard about a Solaris where ar was not installed. Considering Solaris 10 does away with archive libraries, it wouldn't be a big surprise if some future release doesn't include ar by default (though it probably has to be available as an install option for standards conformance). On my Solaris 10 system, ar is installed in /usr/ccs/bin/ar (from SUNWbtool) and /usr/xpg4/bin/ar (from SUNWxcu4). checking for ar... false checking for ranlib... : checking for strip... : And the build then fails later (as expected) on the first use of 'ar' The question was asked Why doesn't configure stop with an error when it finds ar is missing? I didn't have a good answer to that. For the average user the final error message is a hard to decipher. Well yes, but sometimes ar is not needed, for example it /may/ not be needed when --disable-static is given. But if --disable-static is *not* given, shouldn't it be required? Shouldn't libtool's portion of configure fail in that case? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: handling of missing AR
In regard to: Re: handling of missing AR, Ralf Wildenhues said (at 10:25pm...: Shouldn't libtool's portion of configure fail in that case? I'm not really in favor of adding lots of failure points to macros. Sure, there are some hideous cases (missing `file' on Cygwin is, umm, leads to rather unobvious issues, for example), but this one isn't: the build will obviously fail the first time the missing tool is used. Here's a bit of hand-waving why I'm not too fond of hard failures: Completely orthogonal to this issue at hand, there was last week a bug report on one of the Autoconf lists: all but the first-invoked of the macros AC_PROG_CC, AC_PROG_CXX, AC_PROG_F77 would not cause a configure error if the macro won't find a suitable compiler. That lead to weird followup decisions of the configure script. Looking into a fix, let's remember that Libtool-1.5.x (but not CVS HEAD) unfortunately has that bug that it unconditionally calls all of the above, even if the respective languages are not used at all. So users of packages that don't come anywhere near Fortran would need to install a Fortran compiler to be able to successfully run `configure'. Tell that to someone with a system where there is no such thing as a Fortran compiler. I was actually thinking of that exact case. ;-) Right or wrong, configuring a package that used libtool 1.5.x failed for a very long time if there wasn't a C++ compiler installed, even if the package didn't use C++. It took quite a long time before that was fixed (if it even is fixed in 1.5.x -- I don't know). That's much more egregious, IMHO, than having configure error out because a tool that's absolutely needed isn't present. If you're saying it's not possible to tell at configure time whether ar is going to be needed, then I completely agree that things should be left as they are. If, however, we know that ar is going to be required but it's not found at configure time, wouldn't it be better to have configure emit an error message such as: configure: error: An ar command is required for building static libraries. configure with --disable-static if you have no ar command. than having the build fail partway through, with an error that's much less obvious to someone that's not an experienced user? See my point? Hard failure isn't always the best thing to do, if you are writing a macro to be used in other packages. It may be different if you are writing configure.ac: you know that your package will need this and that, and you want early failure. I absolutely agree with that sentiment, but I'm apparently not seeing how it applies in this instance. In the situation you and I were both thinking of and that you describe above, libtool fails when a tool that's *not* explicitly needed isn't installed. I think we both agree that's clearly the wrong thing to do. However, in this situation libtool is detecting that a tool isn't present but allowing configure to proceed. If libtool's configure macro knew at that point that ar was needed but no ar was found, isn't it doing the wrong thing by allowing things to proceed? Here's another way to look at it. Let's say I'm a package author, and my configure.ac calls the appropriate libtool macros. If libtool's portion of configure doesn't error out when something that *libtool* needs isn't available, then doesn't that put the onus back on the package author to do lots of post-libtool-configure checks to make sure that AR, NM, CC, et. al. are defined? Worse yet, the package maintainer now has to be concerned with what (libtool-specific) options were passed to configure (e.g. if --disable-shared was specified, then we may not need to worry about LD). Moreover, the package author may not have any idea what compiler toolchain commands are needed on some esoteric platform that he or she has never seen. That's why the author is using libtool -- so their package supports both archive and shared libraries on multiple esoteric platforms, without the package author having to worry about the details of how it's done or whether the person running configure only wants one or the other type of libraries. The real question is, does libtool's configure macro know whether ar is needed. You seem to be indicating that it never knows (in any case) whether ar is needed. Am I understanding that correctly? Hope this helps a bit. Your libtool posts are always helpful, even when I don't agree with them. ;-) Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: handling of missing AR
In regard to: Re: handling of missing AR, Ralf Wildenhues said (at 7:49am...: If, however, we know that ar is going to be required but it's not found at configure time, wouldn't it be better to have configure emit an error message such as: But how do you know the user will use libtool to build a library even? I've heard of people using AC_PROG_LIBTOOL merely to get the path hardcoding in their programs (for installed third-party packages). There is currently a suggestion on the Automake lists to support partial linking more conveniently, including AC_PROG_LIBTOOL to get at ld -r. Neither of these uses would need ar. Or: what about the crazy package that does not use Automake, invokes AC_PROG_LIBTOOL but uses that to create its libraries only on a few systems (where it deems their own shared library creation system much better)? Yes, I remember to have seen a similar setup. Ralf- These are all good points, and pretty much invalidate my argument. Considering the (mis)uses that a few people are putting libtool to, it's probably best to leave things as is. My point is that you simply often can't know whether it will be used even if you think it will. That's really the crux of the matter, and since it's not possible to know whether it's going to be used, having configure error out is just going to cause new headaches for people. Here's another way to look at it. Let's say I'm a package author, and my configure.ac calls the appropriate libtool macros. If libtool's portion of configure doesn't error out when something that *libtool* needs isn't available, then doesn't that put the onus back on the package author to do lots of post-libtool-configure checks to make sure that AR, NM, CC, et. al. are defined? Worse yet, the package maintainer now has to be concerned with what (libtool-specific) options were passed to configure (e.g. if --disable-shared was specified, then we may not need to worry about LD). Moreover, the package author may not have any idea what compiler toolchain commands are needed on some esoteric platform that he or she has never seen. Right. I completely agree that you have a point here: it would be better to have a configure error here for a majority of users. The real question is, does libtool's configure macro know whether ar is needed. You seem to be indicating that it never knows (in any case) whether ar is needed. Am I understanding that correctly? I am trying to say that I can imagine good uses of AC_PROG_LIBTOOL even without --disable-shared that do not involve `ar'. Here may be an idea to come closer to what you'd like: It's not even that I liked the idea of it erroring; I'm very experienced with autoconf and using configure, so I personally don't like macros that think they're smarter than the person running configure. What I was proposing was based on the misguided notion that configure could know if ar would be needed, and it would be better for the package's maintainer if the problem was caught early and configure complained loudly. If someone that's inexperienced is running configure and they get an obvious error from configure that they're missing something, they're more likely to be able to fix it themselves, which lessens the bug report load for the package's maintainer. maybe by default we should fail on missing AR, LD(?), RANLIB(?), NM(??) (increasingly questionable), and add options to LT_INIT([OPTIONS..]) (which is how CVS Libtool spells AC_PROG_LIBTOOL) that would allow to override this failure. Hmm. Need to think about this. That would at least be better than, say, an interface such as AC_PROG_LIBTOOL([RUN-IF-AR-FAILS], [RUN-IF-NM-FAILS], ...) with all failure arguments defaulting to `:'. :-) I think you've swayed me over to your side now. It *might* be a good idea to AC_MSG_WARN if those things aren't found, but I no longer think it's a good idea to error out. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.22 released.
In regard to: Re: GNU Libtool 1.5.22 released., Ralf Wildenhues said (at...:
Hi Tim,
Tim Mooney writes:
In regard to: Re: GNU Libtool 1.5.22 released., Ralf Wildenhues said (at...:
- I accidentally bootstrapped libtool-1.5.22 with CVS versions of
Autoconf and Automake, instead of using 2.59/1.9.6.
That might explain why the libtool.info file moved. It was installed
under ${prefix}/share/info instead of ${prefix}/info
Ouch.
Well, I'm still uncertain whether this warrants a new release (after all,
the next autotools releases would bring that anyway), but if somebody would
prefer it, I'd agree.
My personal opinion is that this doesn't require a new release. I'm not
sure what changed in the docs between 1.5.20 and 1.5.22, but it seems
likely that even if people install the new docs on their system, they're
probably going to get the old documentation when they fire up info or
whatever they use to read the info docs.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.22 released.
In regard to: Re: GNU Libtool 1.5.22 released., Ralf Wildenhues said (at...:
- I accidentally bootstrapped libtool-1.5.22 with CVS versions of
Autoconf and Automake, instead of using 2.59/1.9.6.
That might explain why the libtool.info file moved. It was installed
under ${prefix}/share/info instead of ${prefix}/info
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: mode=link and full path to dependent shared library?
In regard to: Re: mode=link and full path to dependent shared library?,...: I'm talking about a situation like this: /bin/sh ./libtool --tag=CXX --mode=link cxx -some_compiler_flags -o libfoo.la -rpath /path/to/lib -version-info 16:3:1 -no-undefined foo.lo bar.lo baz.lo /path/to/lib/libdep.so -llib2 -lc -rpath /path/to/lib libtool should be creating libfoo.la (and both shared and archive libfoo libraries) and should be linking against /path/to/lib/libdep.so, but it's eliding the /path/to/lib/libdep.so from the shared library creation line. I'm just trying to find where this behavior is discussed, so I can understand why it's doing that. Does the below fix it for you? Yes, it does. With your patch, there are no changes to output in the libtool test suite on Tru64 (so it didn't break anything that the tests catch), and libtool no longer removes /local/gnu/lib/libintl.so from the link for GNU libaspell.so. Thanks for the patch, it appears to be exactly what I needed! Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mode=link and full path to dependent shared library?
In regard to: Re: mode=link and full path to dependent shared library?,...: I'm talking about a situation like this: /bin/sh ./libtool --tag=CXX --mode=link cxx -some_compiler_flags -o libfoo.la -rpath /path/to/lib -version-info 16:3:1 -no-undefined foo.lo bar.lo baz.lo /path/to/lib/libdep.so -llib2 -lc -rpath /path/to/lib libtool should be creating libfoo.la (and both shared and archive libfoo libraries) and should be linking against /path/to/lib/libdep.so, but it's eliding the /path/to/lib/libdep.so from the shared library creation line. I'm just trying to find where this behavior is discussed, so I can understand why it's doing that. Can you use `-L/path/to/lib -ldep' instead, given that libdep is not part of the package, or maybe `/path/to/lib/libdep.la' if it's a libtool library? The thing is, I'm not the one doing it. The package that exhibits this behavior is GNU aspell, the (dependency) shared library is libintl.so (the GNU gettext library for systems that don't have it in libc), and its full path is coming out of a call to AM_GNU_GETTEXT. After the package (GNU aspell) calls that macro and the Makefiles are generated, the Makefile ends up with LIBINTL = /local/gnu/lib/libintl.so -liconv -lc -rpath /local/gnu/lib Later in the Makefile is the line: libaspell_la_LIBADD = $(LIBINTL) $(PTHREAD_LIB) So, when libtool attempts to create libaspell, the creation of the shared library results in missing symbols, because libtool removed /local/gnu/lib/libintl.so from the link line. I'm pretty sure there is a libtool bug lingering here, but also have a vague feeling that passing this argument to the linker unmodified does not have the same effect on all systems. At least the path hardcoding semantics vary, but maybe taking advantage of this is your intention? I more or less stumbled on this by accident, and was just trying to understand why libtool was removing the shared library that was specified by path. I assumed that the AM_GNU_GETTEXT was doing that for a reason. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
mode=link and full path to dependent shared library?
Can someone point me to the place in the docs that explains libtool's handling of --mode=link when a dependent shared library is specified by full path? I'm having trouble finding it. I'm talking about a situation like this: /bin/sh ./libtool --tag=CXX --mode=link cxx -some_compiler_flags -o libfoo.la -rpath /path/to/lib -version-info 16:3:1 -no-undefined foo.lo bar.lo baz.lo /path/to/lib/libdep.so -llib2 -lc -rpath /path/to/lib libtool should be creating libfoo.la (and both shared and archive libfoo libraries) and should be linking against /path/to/lib/libdep.so, but it's eliding the /path/to/lib/libdep.so from the shared library creation line. I'm just trying to find where this behavior is discussed, so I can understand why it's doing that. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
possible 1.5.20 regression?
In regard to: GNU Libtool 1.5.20 released., Ralf Wildenhues said (at 9:16pm...: The Libtool Team is pleased to announce the release of GNU Libtool 1.5.20. I haven't looked closely at the issue and probably can't for a while yet, but there seems to be a regression on at least Tru64 vs. libtool 1.5.16. I never built 1.5.18 so I don't have that as a comparison point. On Tru64 5.1b with the vendor toolchain, libtool 1.5.16 passes all 103 tests. On the same platform and toolchain, 1.5.20 says it passed all 103 tests, but a couple of the tests generate suspicious output (that wasn't present with 1.5.16) that seems to indicate that the test probably failed but the test suite didn't realize it. Here's the failing output for 1.5.20: PASS: demo-shared.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: hardcode.test 101718:/local/src/RPM/BUILD/libtool-1.5.20/demo/.libs/lt-hell: /sbin/loader: Error: /local/src/RPM/BUILD/libtool-1.5.20/demo/.libs/lt-hell: symbol nothing unresolved 101718:/local/src/RPM/BUILD/libtool-1.5.20/demo/.libs/lt-hell: /sbin/loader: Fatal Error: Load of /local/src/RPM/BUILD/libtool-1.5.20/demo/.libs/lt-hell failed: Unresolved symbol name PASS: build-relink.test PASS: noinst-link.test PASS: demo-unst.test PASS: depdemo-shared.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test 124048:/local/src/RPM/BUILD/libtool-1.5.20/depdemo/.libs/lt-depdemo: /sbin/loader: Error: libl4.so.0: symbol var_l3 unresolved 124048:/local/src/RPM/BUILD/libtool-1.5.20/depdemo/.libs/lt-depdemo: /sbin/loader: Fatal Error: Load of /local/src/RPM/BUILD/libtool-1.5.20/depdemo/.libs/lt-depdemo failed: Unresolved symbol name PASS: build-relink2.test Note that I normally build libtool with one local patch for Tru64, but I have verified that the test output is the same both with and without that patch. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Ralf Wildenhues...: While I agree in principle that it would be nice for libtool to help people avoid shooting themselves in the foot, I think in this case it's more important to document the danger than it is to completely mitigate it. I say this primarily because there might be quite a lot of work to actually get libtool to protect the user. A comment in the docs and likely also in the Solaris C++ section of the code would be good enough, I think, unless someone comes up with an easy way to guard against the issue. How about this? [patch elided] I think it's commit-worthy. It certainly helps outline the issue, and points to a source for more information for the people it impacts. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Ralf Wildenhues...: These two threads contain the patches recently applied to fix the failure with undefined symbols on Solaris with CC (Sun C++ compiler): http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00088.html http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00043.html I've never (manually) created these links or the links for libiostream. The system I tested on does not have above unversioned symlinks, and so links against a libCstd.a with PIC objects. Obviously, the libbaz.so created by the 'tagdemo-shared tagdemo-make' tests then has half of libCstd contained in it. Having this huge lib is both uncomfortable and dangerous: when you start linking against several C++ libraries, you can end up with all sorts of very subtle problems. Then I found this documentation. Now I'm unsure whether we should guard against this issue (I'd like to), but more importantly: I don't know how we _can_ guard against it easily. If I'm following that thread correctly, the original problem (needing -lCstd -lCrun -lc for C++) is fixed with Peter's patch and your subsequent fixups. The new issue is that at least Cstd and probably Crun will be linked statically if the admin hasn't added the symlinks in the appropriate place. While I agree in principle that it would be nice for libtool to help people avoid shooting themselves in the foot, I think in this case it's more important to document the danger than it is to completely mitigate it. I say this primarily because there might be quite a lot of work to actually get libtool to protect the user. A comment in the docs and likely also in the Solaris C++ section of the code would be good enough, I think, unless someone comes up with an easy way to guard against the issue. I suppose the test could be special-cased for Solaris, and ldd or some other tool used after linking to verify that a library we're expecting would show up on the list of NEEDED shared libraries, but that seems like a lot of work. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Albert Chin said...: On Sun, Aug 21, 2005 at 03:46:13PM +0200, Ralf Wildenhues wrote: So I looked around. I've found this documentation http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21): | The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared | version of the libCstd library. | To use the shared version of libCstd, do the following: | 1. As superuser, manually create the following symbolic links. | | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/libCstd.so | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/v8plus/libCstd.so | example% ln -s /usr/lib/sparcv9/libCstd.so.1 \ | /opt/SUNWSpro/lib/v9/libCstd.so We have this compiler on a Solaris 2.6 system and none of /opt/SUNWSpro/lib/libCstd.so, /opt/SUNWSpro/lib/v8plus/libCstd.so, and /opt/SUNWSpro/lib/v9/libCstd.so exist. There is no libCstd.so anywhere in /opt/SUNWspro/lib. I missed earlier parts of this thread, so I'm not sure what's being discussed. We do have the Workshop 6u2 environment, including the C++ compiler. I've never (manually) created these links or the links for libiostream. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
In regard to: Re: FYI: ksh bug on Tru64 UNIX causes current libtool...: * Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: This is a gentle reminder that this issue with Libtool HEAD/branch-2-0 on Tru64 sh is still unsolved. It'd be nice to get a solution into the next 2.0 release candidate, should such a solution exist. Stupid question: Does Tru64 sh need `^' quoted? The one Solaris one does. I.e., does echo Xbla | sed 1s,^X,, work there? (Libtool currently does not quote this consistently.) I haven't seen any responses to this, so I will: it does need it quoted: 05:00 PM dogbert ~$PS1='$ ' /bin/sh $ echo Xbla | sed 1s,^X,, X,,: not found $ sed: Function 1s, cannot be parsed. $ exit Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: Oooh yes; oh yes indeedy. I've come to the conclusion that if your application builds on Tru64 and OS X, then it'll build just about anywhere. I'm surprised by this comment. Tru64 has a more common C API than say AIX or IRIX, and I think HP-UX has only recently caught up some. I've always found it easier to port to Tru64 than the aforementioned platforms. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: And for possible workarounds: Does Tru64 ship another shell suitable for use as CONFIG_SHELL? Please try with CONFIG_SHELL=/bin/foosh /bin/foosh path/to/libtool/configure [OPTIONS] You might try /usr/bin/posix/sh . I'm not sure if it's suitable; hopefully libtool's configure can determine that? As I recall, that's been available since version 4.0, so it's not an option for version 3.2g and earlier. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
OSF versioning and large current/revision/age
All-
I just built atk-1.9.0 (part of gtk+) on Friday, and ran into an issue
with versioning that's making me wonder what kind of problems we may
encounter in the future.
Atk's ABI hasn't changed in quite a while, and because of the way it (and
many other GNU/GNOME packages) increments library versioning, the shared
library is created (by libtool) with a libtool invokation that includes:
-version-info 900:0:900
First, based on inspection of ltmain.in (from 1.5.10), it looks like
libtool doesn't currently handle current/revision/age values with four
or more digits. That's probably going to be a problem for projects like
atk.
Second, on platforms that use OSF-style versioning, that -version-info
argument results in a library creation command line that's almost 11K in
length; 90% or more of that command line length relates to the
test -n 900.900.0:0.0:1.0:.:899.0:900.0 \
-set_version 900.900.0:0.0:1.0:.:899.0:900.0
This results in an IVERSION field in the shared library that's more than
5K in length. At least on Tru64 (I'm not sure about other platforms
that use OSF-like versioning, such as IRIX) that's not a problem for the
loader or the executable itself, but it is excessive. ;-)
Rainer Orth had a good overview of osf versioning vis-Ã -vis libtool in a
message to the list a couple years ago:
http://lists.gnu.org/archive/html/libtool/2002-06/msg00027.html
There was a short thread a couple months later, relating to his patch
waiting to be applied:
http://lists.gnu.org/archive/html/libtool/2002-08/msg00044.html
At the end of that thread, I asked a question that seems to be relevant
again (still): Why is libtool using both SONAME-style versioning *and*
internal versioning, for platforms like Tru64 and IRIX? Does anyone have
any recollection of why that decision was made? The archives are silent
about it. I also don't understand why a .0 is being appended to each
and every interface ( ${iface} ) that's part of $verstring.
In any case, I generally espouse following a particular UNIX flavor's
conventions for building and installing software, but in the particular
case of libtool and osf-style versioning, I've long been concerned that
we might be heading for trouble. libtool's concepts of current, age,
interface, et. al. don't mesh particularly well with IVERSION-style
versioning, IMHO.
I'm considering patching libtool so that it *optionally* uses *just*
soname versioning, similar to Solaris. That way, the person that's
actually building software with libtool can decide if they want libtool to
use the IVERSION field and the soname, or just soname.
I've only partially been following the thread about libtool and MAKEFLAGS,
but it looks like there's a possibility of some kind of $(LIBTOOLFLAGS) that
could be passed to libtool on the command line to control other optional
behavior. I had been considering an environment variable that libtool
would check and parse, but if other optional behavior control is going to
be via command-line flags, it would seem best if my patch piggybacked on
that work.
Comments and suggestions welcome,
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
In regard to: Re: GNU Libtool 1.5.8 released., Bob Friesenhahn said (at...:
When building a multilibed library, a variant of the library could be
built for every possible architectural option, or a subset of the
libraries could be built. It seems to me that being able to choose
from a subset of possible library build options is valuable since
many build options may offer no value to the user. I am not sure
how options would be presented to the installer of
the package, but it should be as easy as possible to select which
variants are build, and it should even be possible for the person
who installs the library to define custom multilib variants to
satisfy local requirements.
I've always envisioned that it would work very similarly to
--{enable,disable}-{shared,static} -- a package that uses libtool
gets a bunch of new configure options for free. What those
options should be is less clear, especially since there will be
differences in what's available for different platforms and OSes.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
In regard to: Re: GNU Libtool 1.5.8 released., Peter O'Gorman said (at...: Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? Well, lets think a bit. We want to add the 64bit specific directories for linux. Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: hardcode_into_libs and Tru64 UNIX
In regard to: Re: hardcode_into_libs and Tru64 UNIX, Tim Mooney said (at...: In regard to: Re: hardcode_into_libs and Tru64 UNIX, Peter O'Gorman said...: Tim Mooney wrote: Anyone know if the reversion to hardcode_into_libs=no was an intentional change, and if so what the reasoning was? I have no idea, and a quick ChangeLog grep was not enlightening. If you feel like posting a patch with ChangeLog entry to -patches I'll apply it. I would be willing to do that, but libtool 1.5.6 with hardcode_into_libs=no passes all 101 test on Tru64 UNIX 5.1b. libtool 1.5.6 with hardcode_into_libs=yes fails 2 of 97 tests, and skips 4 others. I haven't had a chance to look at what that's happening. The tests are: FAIL: demo-make.test SKIP: demo-exec.test SKIP: demo-inst.test FAIL: pdemo-make.test SKIP: pdemo-exec.test SKIP: pdemo-inst.test I did some more testing of this over the weekend. It's not my patch that's causing this, it's that after the patch demo/Makefile.in and pdemo/Makefile.in need to be rebuilt, and automake (I've tried 1.8.2 and 1.8.5) is exiting with an error: cd /local/src/RPM/BUILD/libtool-1.5.6/tests/../demo /bin/ksh /local/src/RPM/BUILD/libtool-1.5.6/missing --run automake-1.8 --foreign Makefile.am: object `hello.$(OBJEXT)' created both with libtool and without Makefile.am: object `foo.$(OBJEXT)' created both with libtool and without gmake[3]: *** [/local/src/RPM/BUILD/libtool-1.5.6/tests/../demo/Makefile.in] Err or 1 gmake[3]: Leaving directory `/local/src/RPM/BUILD/libtool-1.5.6/demo' and cd /local/src/RPM/BUILD/libtool-1.5.6/tests/../pdemo /bin/ksh /local/src/RPM/BUILD/libtool-1.5.6/missing --run automake-1.8 --foreign Makefile.am: object `longer_file_name_hello.$(OBJEXT)' created both with libtool and without Makefile.am: object `longer_file_name_foo.$(OBJEXT)' created both with libtool and without gmake[3]: *** [/local/src/RPM/BUILD/libtool-1.5.6/tests/../pdemo/Makefile.in] Er ror 1 gmake[3]: Leaving directory `/local/src/RPM/BUILD/libtool-1.5.6/pdemo' Interestinly, if I do make check; make check; The first set fails 2 and skips 4, the second check passes all 101 tests, which means that Makefile.in is being updated, even though automake is exiting with an error. BTW, after looking closer at the test suite, I have a couple questions: - Are there plans to modify the test suite to use the 1.5.x tagging mechanism that Albert introduced, so that the test cases only use the parts of libtool they need (i.e. don't do a bunch of C++ and Fortran checks for a testsuite that only uses C) - Is it necessary to have identical copies of `acinclude.m4' in each of the demo directories and the top level libtool directory? Must those directories be completely self-contained, or could they just reference/include the top level acinclude.m4? I'll send along my original hardcode_into_libs patch for Tru64, but I think someone else is going to need to figure out how to pacify automake in the test suite. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: building libtool on Tru64 Unix
In regard to: building libtool on Tru64 Unix, Janet Goldstein said (at...: I am trying to build libtool 1.5.6 on Tru64 Unix. using './configure --enable-dynamic'. The 'make' dies thusly: Janet- I've never seen this particular problem on Digital UNIX or Tru64 UNIX. The obvious differences I can see between your build and my typical builds are - I use GNU make. Not sure if it's required, but I'm suspicious about `config.status' being run as a dependency. Try using GNU make for the build process. - I don't specify `--enable-dynamic' when configuring, as the default is to enable both static and dynamic. -- yew:/u01/home/jgold/download/libtool-1.5.6 make No suffix list. Making all in . No suffix list. CONFIG_FILES=libtoolize CONFIG_HEADERS= /bin/ksh ./config.status config.status: creating libtoolize config.status: executing depfiles commands chmod +x libtoolize Making all in libltdl make all-am /bin/ksh ./libtool --mode=compile cc -std1 -DHAVE_CONFIG_H -I. -I. -I. -g -c -o ltdl.lo ltdl.c ./libtool: invalid operation mode `--mode=compile' Try `./libtool --help' for more information. *** Exit 1 Stop. *** Exit 1 Stop. *** Exit 1 Stop. -- Can anyone give me a hint as to what the problem might be? Thanks. Nothing obvious jumps out. Do you have an older version of libtool installed on the box? How about libtool.m4 and ltdl.m4? If you do, try removing all of those things, and do a fresh un-tar, configure, make (with GNU make), and see what happens. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hardcode_into_libs and Tru64 UNIX
In regard to: Re: hardcode_into_libs and Tru64 UNIX, Peter O'Gorman said...: Tim Mooney wrote: Anyone know if the reversion to hardcode_into_libs=no was an intentional change, and if so what the reasoning was? I have no idea, and a quick ChangeLog grep was not enlightening. If you feel like posting a patch with ChangeLog entry to -patches I'll apply it. I would be willing to do that, but libtool 1.5.6 with hardcode_into_libs=no passes all 101 test on Tru64 UNIX 5.1b. libtool 1.5.6 with hardcode_into_libs=yes fails 2 of 97 tests, and skips 4 others. I haven't had a chance to look at what that's happening. The tests are: FAIL: demo-make.test SKIP: demo-exec.test SKIP: demo-inst.test FAIL: pdemo-make.test SKIP: pdemo-exec.test SKIP: pdemo-inst.test Until I have a chance to look at what's going on, I don't want to submit a patch that I know will cause regressions in the test suite. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
hardcode_into_libs and Tru64 UNIX
In the 1.4.x series, hardcode_into_libs=yes for Tru64 UNIX, which seems like fine behavior to me. At some point in 1.5.x that was removed, so the default of hardcode_into_libs=no is now in place. I can't find anything in the ChangeLog or list archive about why that change was made. About the only relevant hit in the list archive search is Albert's request to make it yes for Tru64 et. al.: http://mail.gnu.org/archive/html/libtool/2001-12/msg00032.html Anyone know if the reversion to hardcode_into_libs=no was an intentional change, and if so what the reasoning was? Thanks, Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: building libtool libraries for multiple ABIs
In regard to: Re: building libtool libraries for multiple ABIs, Albert Chin...: On Tue, Apr 27, 2004 at 04:58:54PM -0500, Tim Mooney wrote: If you want to build and install a local package (take for example GSL, the GNU Scientific Library) that builds a library via libtool, what are people doing to have the library built for each ABI that a platform may support? Has anyone found a better method than configuring the package, building and installing once, then reconfiguring with CFLAGS and LDFLAGS set for a different ABI and overridding the library directory, and building and installing again? This can become a pretty tiresome process, especially if you also package your local software (such as with RPM) and install the package. How are other people dealing with this issue? What other solution is there than rebuilding? I haven't found one, but I was hoping someone else had. I guess the question I have is, Is this something that some future version of libtool should support naturally and automatically?. Libtool is already building two kinds of libraries (archive and shared) with two kinds of object files (non-PIC and PIC) on platforms where those distinctions exist. Should another factor be added, so that libtool will (optionally) build those two kinds of libraries for N (where N is commonly 2) kinds of ABIs, on a platform that supports multiple ABIs? When we build software, we build most packages to a _separate_ directory. So, for GSL, we have something like /opt/libgsl13 and /opt/libgsl14. When we build 64-bit versions of these, we build as usual but set --libdir=/opt/libgsl13/lib/64. Exactly what I figured I would have to do, but if (and it's a big if) it were decided that libtool should support multiple ABIs, it would seem that libtool could handle that bit automatically, and you could again go back to a simple configure --prefix=/opt/libgsl14 --exec-prefix=/opt/libgsl14 make make install Anyway, I appreciate your comments. You've verified for me that there's probably not some magically easy way to do this that I'm just not seeing. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
building libtool libraries for multiple ABIs
All- I've managed to avoid (more like ignore) the issue of how to deal with multiple platform ABIs and libtool libraries in the past, but I'm now faced with the issue for real, and I'm wondering if anyone has any suggestions for best practices that have worked for them. What I'm talking about are platforms (like IRIX and Solaris, but more recently Linux and Mac OS X) where the OS is capable of running multiple types of binaries. For example, on IRIX you have the 64 bit ABI and the new 32 bit ABI (let's forget about the old 32 bit ABI). Libraries built for one ABI cannot be linked with objects built for a different ABI, so the system has segregated library directories and the linker chooses the correct library based on either the command line flags it receives or the type of the first object file it sees. If you want to build and install a local package (take for example GSL, the GNU Scientific Library) that builds a library via libtool, what are people doing to have the library built for each ABI that a platform may support? Has anyone found a better method than configuring the package, building and installing once, then reconfiguring with CFLAGS and LDFLAGS set for a different ABI and overridding the library directory, and building and installing again? This can become a pretty tiresome process, especially if you also package your local software (such as with RPM) and install the package. How are other people dealing with this issue? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Link flags that get ignored
In regard to: Link flags that get ignored, Josep M. Perez Cancer said (at...: I am using libtool to create a library on mips-sgi-irix6.5 with the following constraints: CC=cc (The platform C compiler) CFLAGS=-64 (64 bits) CXX=CC (The platform C++ compiler) CXXFLAGS=-LANG:std -64 (C++ conformity flag and 64 bits) LDFLAGS=-64(64 bits) Libtool doesn't pass the -64 argument to the linker, and then I can't create a 64 bit library. I have had the same problem with other architectures before. Is there any way I can make it not ignore the flag? What happens if you go completely around libtool, and set SGI_ABI before you invoke libtool (and then don't pass -64 to anything via CC/CFLAGS etc.)? See the ABI(5) man page for more information. Also, whether or not that works, what happens if you instead do: CC='cc -64 -Wl,-64' CXX='CC -64 -Wl,-64' CXXFLAGS='-LANG:std' LDFLAGS='-64' Do either of these work around the problem successfully? Ideally libtool should be passing the link flags unmolested, but it's not (yet) perfect. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.3 searches /usr/lib before -Ldir
In regard to: libtool 1.4.3 searches /usr/lib before -Ldir, Pieter...: I've asked for help about this problem twice in the last few weeks, without any replies. I saw your posts, but don't recall whether this is something you've tried with libtool 1.5.2 or not. Have you? The libtool developers have expressed extreme reluctance to spend much time on code that is an evolutionary dead end. All new work is going into the 1.5.x and later lines of development. In the meantime I've done some searching in the libtool list history, and I came across this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04324.html If you download libtool 1.4.3 and look at ltmain.in, you'll see about a dozen places where newlib_search_path is set to something. In each case, the assignment ends up looking like newlib_search_path=$newlib_search_path something else here If you try systematically changing these to newlib_search_path=something else here $newlib_search_path you should eventually be able to arrive at the combination of settings that are causing the problem for you. My *guess* (and that's all it is) is that it's either the place where it's under a case for `-L', or it's the place where you have newlib_search_path=$newlib_search_path $ladir Do some testing, and report back what you find. Better yet, test with libtool 1.5.2. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.5.x linking regression on Tru64 (-pthread)
I believe I've discovered a regression in libtool 1.5.x, at least on Tru64 UNIX. I'm using the vendor cc compiler. Given a project that uses libtool 1.4.3 and also uses pthreads, it's common to have `-pthread' in CFLAGS when configuring the project. The man page for cc defines -pthread as: -pthread Directs the linker to use the threadsafe version of any library speci- fied with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads inter- faces in libpthread when linking the program. This option also defines the _REENTRANT macro. In any case, for 1.4.3 compiling with libtool works correctly, and linking shared libraries also works as expected. If the project is updated to use libtool 1.5.2, though, linking fails, because `-pthread' is now being passed to ld, and ld doesn't understand that option. I haven't had a chance to look much at the problem, but thought I would report it. Please let me know if I can provide additional information. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Incorrect library suffix on newer HP-UX (.sl vs .so)
In regard to: RE: Incorrect library suffix on newer HP-UX (.sl vs .so),...: Tim, hpux under pa-risc (even 64-bit) still uses the .sl extension even where 64-bit ELF libraries are concerned. Only under the Intel architecture does it use the .so filename. If you want to have a look for yourself, HP gives out shell access under their testdrive program, which gives you access to a slew of different OS/arch combinations (like Alpha/FreeBSD ia64/hpux11). Robert (and Ross Alexander)- Thanks for the clarifications! So the stuff I said about no ia64 in 9.x (and 10.x?) is true, as is the stuff about SOM in 9.x and 10.x (at least on PA -- does anyone remember if 680X0 support was still in 9.x, and if so if it was also SOM?) but the stuff I said about 11.x is mostly incorrect. I was going off of memory, which clearly isn't very good... Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: LD_RUN_PATH not adding paths when building with shared libs
In regard to: Re: LD_RUN_PATH not adding paths when building with shared...: On Thu, Aug 28, 2003 at 05:36:50PM -0500, Tim Mooney wrote: Are you assuming LD_RUN_PATH is something that's honored on IRIX because you've seen it honored on other platforms (e.g. Solaris?). If you've seen it documented somewhere that it should work on IRIX, can you provide information on where I should look? The original problem was the built binary was not finding libgcc. The first solution was to use LD_RUN_PATH and --disable-shared which worked. [this isn't really an autoconf issue, so I'm removing autoconf from the Cc: list] I would imagine that just --disable-shared would have been all that was needed -- LD_RUN_PATH is just a red herring in this case. On linux --disable-shared allowed the use of LD_RUN_PATH (because of lack of --rpath at link time). So I assume that's what was happening. But, on IRIX with --disable-shared libgcc does not show up in ldd output. It's apparently caused libgcc to be linked statically, then. Another solution was to use -R /path/to/libgcc in LDFLAGS. That also works at building the program but then libgcc is shown in ldd output (and they commented they might want to use the binary on another IRIX machine without libgcc installed). Then their only option is to link libgcc in statically. I don't understand why --disable-shared would make that difference. This project uses libtool to create a library, and then links it into our program. I thought --disable-shared prevented the creation of the shared library (that we are building in our project). On linux when I use --disable-shared ldd swish-e no longer shows libswish-e, but that's the only difference. So now I wonder why their tests on IRIX showed that --disable-shared also statically linked in libgcc. It does seem there's a discrepancy in how it behaves across platforms, if what you're saying is true. I no longer have the original email that showed the commands executed and the output, but it might be useful to see the libtool command that's being run to create the shared library, followed by the commands that libtool is executing on your behalf, and similar libtool/underlying commands for when `swish-e' is linked. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: LD_RUN_PATH not adding paths when building with shared libs
In regard to: LD_RUN_PATH not adding paths when building with shared libs,...: [please cc, as I don't seem to be getting mail from the lists - and my subscribe confirm messages are not getting to me] This is still trying to work out problems on IRIX where a needed library is not in the default search path (libgcc_s.so.1). Tried using LD_RUN_PATH to point to libgcc but that wasn't working without using LD_LIBRARY_PATH at run time. So, it seems like the LD_RUN_PATH path is not used when building our project unless we use --disable-shared: This project uses libtool and automake. It builds a library that is installed using libtools and also a binary linked against that library. I'm not clear if this is expected beharior or not. I'd think LD_RUN_PATH should be available regardless if building shared or not: First, if not using --disable-shared my LD_RUN_PATH is not set in the binary: Are you assuming LD_RUN_PATH is something that's honored on IRIX because you've seen it honored on other platforms (e.g. Solaris?). If you've seen it documented somewhere that it should work on IRIX, can you provide information on where I should look? The reason I'm asking is because I've never seen LD_RUN_PATH referenced on IRIX, and I thought I understood shared libraries on IRIX fairly well. LD_RUN_PATH isn't mentioned in the ld man page. If it's actually honored by the linker, you should be able to create a very simple C test program, copy your shared C library (for the ABI you're compiling for) into a temporary directory like /tmp/test-run-path, set the LD_RUN_PATH variable to point to that directory, and then compile your C program and link it against that copy of the shared C library. If ldd or elfdump turn up an `RPATH' in the binary, then LD_RUN_PATH was probably honored. If not, it probably wasn't. In my tests, it looks like it's not honored, which matches my experiences. [EMAIL PROTECTED]:~/swish-e$ ./configure --prefix=$HOME/test_again /dev/null [EMAIL PROTECTED]:~/swish-e$ LD_RUN_PATH=/home/moseley/swish-e/filters make install /dev/null [EMAIL PROTECTED]:~/swish-e$ strings /home/moseley/test_again/bin/swish-e | grep moseley /home/moseley/test_again/lib /home/moseley/test_again/lib/swish-e (By the way, I'm sure I used to know a better way to show the search path for a binary than using strings!) I generally use `ldd', though `elfdump' is also a useful tool on IRIX, assuming you're talking about the runpath (RPATH or DT_RPATH) that the loader uses. Now try with --disable-shared: [EMAIL PROTECTED]:~/swish-e$ ./configure --disable-shared --prefix=$HOME/test_again /dev/null [EMAIL PROTECTED]:~/swish-e$ LD_RUN_PATH=/home/moseley/swish-e/filters make install /dev/null [EMAIL PROTECTED]:~/swish-e$ strings /home/moseley/test_again/bin/swish-e | grep moseley /home/moseley/swish-e/filters /home/moseley/test_again/lib/swish-e Now LD_RUN_PATH is getting in the binary. Is this expected? You don't know that it's LD_RUN_PATH that's causing /home/moseley/swish-e/filters to appear in the binaries, though, do you? Couldn't be that it's getting in there because of some other reason? If it is expected how should users that have other library requirements (like libgcc on IRIX) add in a path at build time? If the library doesn't specify it itself, the only way I'm aware of is via the `-rpath' option of ld. The linker will include the RPATH from libraries in the binary it generates, though, so you wouldn't need -rpath when linking your binary if libgcc_s.so.N internally specified an RPATH for where to find it and its dependencies. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Installed vs built library
In regard to: Installed vs built library, Luigi Ballabio said (at 11:23am...: What am I doing wrong? Thanks, Luigi P.S. Almost forgetting: libtool 1.4.3, automake 1.7.6, autoconf 2.57 The libtool maintainers want to focus their efforts on libtool 1.5, and will likely encourage you to use that version instead. If you try libtool 1.5 and encounter the same problem, send another message to the libtool list with information similar to what you provided in your original message. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: IRIX inheriting RPATH of libraries
In regard to: IRIX inheriting RPATH of libraries, Albert Chin said (at...: Ugh! Looks like IRIX will inherit the RPATH of a library. So, say program foo is linked against libbar2.so and libbar2.so is dependent on libbar1.so. At build time, the runtime path of the .libs directory containing libbar1.so will be added to the RPATH entry of libbar2.so. Then, when program foo is created, this .libs directory is added to the RPATH entry of program foo. Because program foo is not relinked at install time, it keeps this RPATH entry. Looks like we need another variable, inherit_rpath, that relinks programs when true. I must be missing something, because I'm not seeing how that's different from other osf-style linkers. Tru64 executables pick up the DT_RPATH from each and every library they link directly against -- I guess I've never thought about or checked whether they pick up the RPATH for libraries that their libraries depend on. I know you're very familiar with the Tru64 linker/loader behavior. Can you explain what's different that you're surprised about in the IRIX linker vs. the Tru64 linker or other osf-style linkers? I actually like and have made great use of the executables pick up the RPATH entries for libraries they link against. It can be very handy. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
versioning rationale for IRIX/OSF
I've been using libtool for years, hacking on it for personal use for a while, and on this list for a year or so. One thing I've never understood about libtool is why it uses both SONAME style versioning *and* internal versioning on platforms like IRIX and Tru64. In the past I've hacked out the SONAME style versioning on those two platforms so that it just uses `libwhatever.so' as the SONAME, and the versioning is done via the internal versioning field. Still there are advantages to using SONAME-based versioning (i.e. it's slightly easier to have multiple versions of a library available on a platform). What I don't get is the rationale for using both styles. Can anyone enlighten me regarding this issue? Thanks! Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.2 on Darwin
In regard to: Re: libtool 1.4.2 on Darwin, Christoph Egger said (at 11:26pm...: Ok, here we come: I just did 2) The fix is replacing this line archive_cmds='$nonopt $(test x$module = xyes echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags -install_name $rpath/$soname $verstring' by this one: archive_cmds='$nonopt $(test .$module = .yes echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $ libobjs $deplibs$linker_flags $(test .$module = .yes || echo -install_name $rpath/$soname) $verstring' I can understand the change for quotes, but why the change from x$module and xyes to .$module and .yes? Is that really necessary? What about other parts of libtool that use x$var = xfoo. If possible, keeping it consistent would be best. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Library coding standards question
In regard to: Library coding standards question, jks said (at 12:42am on...: Choose a name prefix for the library, more than two characters long. All external function and variable names should start with this prefix. In addition, there should only be one of these [one name prefix, one external function, one variable name, or one of something else?] in any given library member [what is the meaning of library member in this context?]. This usually means putting each one [one what?] in a separate source file. A name prefix just means that for C libraries, all your visible symbols should start with some kind of prefix, i.e. your API shouldn't have functions like read() write() etc., but instead use jkslib_read() jkslib_write() etc. That's because of the problem with namespace pollution/collision in C. This isn't as much of an issue for libraries in some other languages, but it's still worth considering. A member is generally one object file. The guidelines are saying that if your `libjks.a' or `libjks.so' or whatever has multiple members *and* those members have multiple name prefixes (e.g. you have externally visible symbols jkslib_read() and jkslib_write() to read and write your new JKS video format, and you also have mpeg4_read() and mpeg4_write() to handle MPEG4 video format), then the externally visible functions should be in separate members: cc -o jks.o -c jks.c cc -o mpeg4.o -c mpeg4.c ar -crv libjks.a jks.o mpeg4.o nm -B libjks.a jks.o: 0x80 T jkslib_read 0x000d90 T jkslib_write mpeg4.o: 0x0001f0 T mpeg4_read 0x000b40 T mpeg4_write That doesn't illustrate the use of libtool, but it does illustrate what the text you've quoted is talking about. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool error
In regard to: Libtool error, Kemp Randy-W18971 said (at 3:12pm on Oct 8, 2001): libtool: ltconfig version `' does not match ltmain.sh version `1.3.5' Fatal configuration error. See the libtool docs for more information. It means that the version of libtool that the package thinks its using doesn't jive with the ltmain.sh that's in the package directory. This commonly happens if you try update the libtool source file(s) themselves, without also rebuilding configure from configure.in. Did you manually or through `libtoolize' install a different version of ltmain.sh than the one that ships with the package? Assuming you have libtool, automake, and autoconf installed on your build machine, you can often alleviate this problem by doing cd package-top-directory rm -f ltmain.sh ltconfig libtool rm -f aclocal.m4 libtoolize --copy --force aclocal autoconf Depending on the package and what you have installed on your box, more may be needed than just that. That's kind of a big hammer approach, though. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libltdl 64-bit lint
In regard to: Re: libltdl 64-bit lint, [EMAIL PROTECTED] said...:
static lt_ptr
realloc (ptr, size)
lt_ptr ptr;
size_t size;
{
if (size = 0)
Is size_t always unsigned?
It is on all the platforms I've seen -- that's why there's an ssize_t
(signed size_t).
sprintf (filename, %.*s/%s, (int) dirname_len, dirname, dlname);
According to sprintf(3) on a Linux box, when using %*, the field width
must be of type int.
The other man pages I've seen agree.
(3235) warning: argument #4 is incompatible with prototype:
prototype: pointer to void : ltdl.c, line 2159
argument : pointer to function(pointer to const char, pointer to void)
returning int
(3241) warning: argument #4 is incompatible with prototype:
prototype: pointer to void : ltdl.c, line 2159
argument : pointer to function(pointer to const char, pointer to void)
returning int
(3245) warning: argument #4 is incompatible with prototype:
prototype: pointer to void : ltdl.c, line 2159
argument : pointer to function(pointer to const char, pointer to void)
returning int
(3252) warning: argument #4 is incompatible with prototype:
prototype: pointer to void : ltdl.c, line 2159
argument : pointer to function(pointer to const char, pointer to void)
returning int
(3259) warning: argument #4 is incompatible with prototype:
prototype: pointer to void : ltdl.c, line 2159
argument : pointer to function(pointer to const char, pointer to void)
returning int
We've already discussed this. No clear solution.
There is one, though I never brought it up before because all current
compilers I've seen accept the code (so it didn't seem to be worth
worrying about).
The portable solution would be to not overload what the pointer points
to. Instead, define a struct or a union that has members of the
appropriate type (pointer to an function with the right type, or a pointer
to the right struct type, or whatever else the function needs to be able
to return), and then return a pointer to that struct (or union). That
way you're always returning a pointer to a struct or union of a particular
type, it's just that different functions make use of different members of
the struct or union.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: use of __STDC__ in libtool.m4 on HEAD
In regard to: Re: use of __STDC__ in libtool.m4 on HEAD, Gary V. Vaughan...: Why? Some C compilers define __STDC__ but don't define it to 1. How about: #ifdef __STDC__ I believe there are compilers out there that define __STDC__ to 0 for strict KR mode and to 1 for strict ANSI mode. If memory srves, OSF compilers used to this -- at least in the 3.2 series... No, __STDC__ defined to 0 means ANSI + extensions for at least the recent Tru64 compiler (and I think that behavior goes back quite far). The Sun FORTE compiler does the same thing if given either the `-Xa' or `-Xt' option (ANSI+ or ANSI transitional, accordingly). If anyone is defining __STDC__ as anything in strict KR mode, it's a bug in the compiler. __STDC__ should never be defined for KR (only). How about: #if defined (__STDC__) !__STDC__ What happens if __STDC__ is 1 (as it should be for strict ANSI conformance)? I think Albert's suggestion of dropping the ... is the right one. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c and 1.4.1 (type conflicts)
In regard to: Re: ltdl.c and 1.4.1 (type conflicts), Gary V. Vaughan said...: Except that the function argument takes an lt_ptr which it passes through to a callback function. Sometimes it is a pointer to a structure that the callback uses, other times it is a pointer to a function. Creating two identical functions, but for whether they pass through a pointer to a function or a pointer to something else is not a good idea... I really think that the warning from xlc is misconceived. Except it's not just xlc, it's Sun's Forte 6.1, recent versions of the Tru64 UNIX C compiler, HP-UX 10.20's ANSI C compiler, and possibly others. Even gcc 3.x can be made to warn about it. ;-) None of them error out on it, but they all warn that it's against the standard. Maybe that's changed with C9X, so it's no longer a problem -- I don't know. In any case, since no one has pointed out a compiler that won't accept this, it's probably not worth worrying about at this point. Indeed. But KR vs. ANSI is not the reason for this problem. Anyway, supporting KR is really not at all difficult, so I have no problem at all with doing it. As long as it's not a problem for you, great! Hopefully it never becomes an issue. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c and 1.4.1 (type conflicts)
In regard to: Re: ltdl.c and 1.4.1 (type conflicts), Gary V. Vaughan said...: P.S. Tim, your return address does not exist according to DNS... I'm removing the hostname part for this message incase that works. I'm not sure how that happened, but nothing's changed on my end mailwise. Should still work fine. Are you sure your response (that bounced) wasn't to someone else's email, that might have accidentally trimmed out part of the necessary bits? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c and 1.4.1 (type conflicts)
In regard to: Re: ltdl.c and 1.4.1 (type conflicts), Bruce Korb said (at...: Tim Mooney wrote: Something similar to what's done on page 147 (section 6.7) of KR2e -- KR2e == ANSI Of course, most of the functions still use the KR style arg definitions. KR1e. Thanks for clarifying what I was trying to say, but not being quite explicit enough, apparently. BTW, you trimmed a bit too much of my address, which is why Gary's response bounced for him. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS,...: The first paragraph of the dlopen() man page on Tru64 UNIX 5.1 (and 4.0f) says that The dlopen function attempts to load the specified file in the address space of the process, resolving symbols as appropriate. Any libraries that the specified file depends upon are also loaded. The loader on Tru64 UNIX 5.0A and below will load not load dependent libraries for a shared library. Albert- I believe that's incorrect, and it's certainly contrary to how things are documented to act. RPATH is honored for executables but not for libraries. That *is* correct. You'll need a test program to determine if this has been fixed under 5.1 but I doubt it. It has not. I have it directly from the loader author/maintainer that honoring RPATH in libraries is coming to a future version of Tru64, but it's not here yet. I summarized about this issue on the tru64-unix-managers mailing list several months back. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS,...: And if libltdl_cv_sys_dlopen_deplibs=yes is true for a platform but the platform loader does not honor RPATH in shared libraries and a shared library being dlopen'ed has a dependency on another library whose path is not in the application RPATH, should libltdl_cv_sys_dlopen_deplibs still be yes for this platform? I actually followed that. :-) My vote would be yes, but there should probably be a separate libltdl_cv_sys_dlopen_honors_rpath or maybe libltdl_cv_sys_dlopen_honours_rpath for Gary et. al. ;-) Maybe `respects' or `obeys' or `uses' would be better than honors/honours. Both of these things could be tested using variants of Robert's test code, updated a little for use with ltdl. An earlier question I asked still remains, though: what about platforms that have a different API for dynamic loading, e.g. HP-UX 11.x? Does this cache value (or these cache values) apply there as well, even though the system uses shl_load instead of dlopen()? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: On Friday 13 July 2001 11:25 pm, Robert Boehne wrote: I added AIX to your list and wrote a test program to test it on both IRIX and AIX. The dependent lib was opened under irix 6.5.8 and aix 4.3.3. Here is a slightly revised patch against HEAD. OK to commit? Unless you are reasonably sure otherwise, I'd rather see the case statments tightened up so that the unproven cases are left with the default (unknown) value, effectively documenting our collective knowledge about the architectures in the code instead of in comments. Ok, I'm working on it. I'll have a patch later today or tomorrow. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: Here is the test case, if someone wants to libtoolize it, we could add it to the macro. Seconded! I would happily accept a patch to perform the test *instead* of listing values for only hosts triplets that have been researched... :-) For now, what do you think of the updated patch, below? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 diff -ur libtool-1.4b.orig/ltdl.m4 libtool-1.4b/ltdl.m4 --- libtool-1.4b.orig/ltdl.m4 Thu Jul 5 18:10:26 2001 +++ libtool-1.4b/ltdl.m4Mon Jul 16 16:06:34 2001 @@ -70,13 +70,57 @@ [AC_REQUIRE([AC_CANONICAL_HOST]) AC_CACHE_CHECK([whether deplibs are loaded by dlopen], libltdl_cv_sys_dlopen_deplibs, [dnl - # PORTME does your system automatically load deplibs for dlopen()? + # PORTME does your system automatically load deplibs for dlopen() + # or its logical equivalent (e.g. shl_load for HP-UX 11) + # For now, we just catch OSes we know something about -- in the + # future, we'll try test this programmatically. libltdl_cv_sys_dlopen_deplibs=unknown case $host_os in + aix3*|aix4.1.*|aix4.2.*) + # Unknown whether this is true for these versions of AIX, but + # we want this `case' here to explicitly catch those versions. + libltdl_cv_sys_dlopen_deplibs=unknown + ;; + aix4*) + # Unknown whether this is true for aix5, but is true for aix = 4.3.* + libltdl_cv_sys_dlopen_deplibs=yes + ;; + irix[12345]*|irix6.[01234]*) + # Catch all versions of IRIX before 6.5, and indicate that we don't + # know how it worked for any of those versions. + libltdl_cv_sys_dlopen_deplibs=unknown + ;; + irix*) + # The case above catches anything before 6.5, and it's known that + # at 6.5 and later dlopen does load deplibs. + libltdl_cv_sys_dlopen_deplibs=yes + ;; linux*) libltdl_cv_sys_dlopen_deplibs=yes ;; netbsd*) + libltdl_cv_sys_dlopen_deplibs=yes + ;; + osf[1234]*) + # dlopen did load deplibs (at least at 4.x), but until the 5.x series, + # it did *not* use an RPATH in a shared library to find objects the + # library depends on, so we explictly say `no'. + libltdl_cv_sys_dlopen_deplibs=no + ;; + osf5.0|osf5.0a|osf5.1) + # dlopen *does* load deplibs and with the right loader patch applied + # it even uses RPATH in a shared library to search for shared objects + # that the library depends on, but there's no easy way to know if that + # patch is installed. Since this is the case, all we can really + # say is unknown -- it depends on the patch being installed. If + # it is, this changes to `yes'. Without it, it would be `no'. + libltdl_cv_sys_dlopen_deplibs=unknown + ;; + osf*) + # the two cases above should catch all versions of osf = 5.1. Read + # the comments above for what we know about them. + # At 5.1, deplibs are loaded *and* any RPATH in a shared library + # is used to find them so we can finally say `yes'. libltdl_cv_sys_dlopen_deplibs=yes ;; solaris*) --- libtool-1.4b.orig/ChangeLog Mon Jul 9 17:02:09 2001 +++ libtool-1.4b/ChangeLog Mon Jul 16 16:10:41 2001 @@ -0,0 +1,5 @@ +2001-07-16 Robert Boehne [EMAIL PROTECTED], Tim Mooney +[EMAIL PROTECTED] + + * ltdl.m4 (AC_LTDL_SYS_DLOPEN_DEPLIBS): add cases and comments for + more platforms, including AIX, Digital/Tru64 UNIX and IRIX. + ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: And if libltdl_cv_sys_dlopen_deplibs=yes is true for a platform but the platform loader does not honor RPATH in shared libraries and a shared library being dlopen'ed has a dependency on another library whose path is not in the application RPATH, should libltdl_cv_sys_dlopen_deplibs still be yes for this platform? No, on reflection, I don't think it should. This is a subtlety that is worth documenting for future porters, so I will find somewhere to add it to the distribution presently. I added some notes to libtool.texi about the issue. I'll send the patch to the libtool-patches list. Take a look, and see what you think. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: On Thursday 12 July 2001 8:12 pm, Tim Mooney wrote: I'm not 100% sure I know what whether deplibs are loaded by dlopen means. Does it mean: If you explicitly load a shared object via dlopen(), are any shared objects that it depends on loaded for you automatically? Yes, exactly that. Does this macro apply at all to platforms that have some other mechanism of dynamically loading a shared object (e.g. HP-UX 10.x and earlier)? The first paragraph of the dlopen() man page on Tru64 UNIX 5.1 (and 4.0f) says that The dlopen function attempts to load the specified file in the address space of the process, resolving symbols as appropriate. Any libraries that the specified file depends upon are also loaded. On IRIX 6.5.x, it's not nearly so clear, but that man page does say (when talking about DSOs that are flaged for delayed loading, and I'm guessing the same applies elsewhere): If it has any entries in its library list that are not marked LL_DELAY_LOAD, the DSOs that are not delay-loaded are added recursively (breadth-first). Depending on the order of calls to delay-loaded DSOs, the order of DSOs on the rld-list might be different from one run of a program to the next. Of course, if I really wanted to test on IRIX it could be tested programmatically, but I'm not sure I want to whip up the test case to do it. I think the enclosed patch should be correct, for at least recent versions of both Tru64 and IRIX. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 --- libtool-1.4b.orig/ltdl.m4 Thu Jul 5 18:10:26 2001 +++ libtool-1.4b/ltdl.m4Fri Jul 13 15:45:31 2001 @@ -73,10 +73,20 @@ # PORTME does your system automatically load deplibs for dlopen()? libltdl_cv_sys_dlopen_deplibs=unknown case $host_os in + irix6*) + # Unknown if this has always been true, even for early versions of + # 6.x, but it's true as of 6.5.x + libltdl_cv_sys_dlopen_deplibs=yes + ;; linux*) libltdl_cv_sys_dlopen_deplibs=yes ;; netbsd*) + libltdl_cv_sys_dlopen_deplibs=yes + ;; + osf*) + # Unknown if this has always been true (i.e. for 1.2 - 3.2g). It + # is true for 4.x and later. libltdl_cv_sys_dlopen_deplibs=yes ;; solaris*) --- libtool-1.4b.orig/ChangeLog Mon Jul 9 17:02:09 2001 +++ libtool-1.4b/ChangeLog Fri Jul 13 15:48:45 2001 @@ -0,0 +1,5 @@ +2001-07-13 Tim Mooney [EMAIL PROTECTED] + + * ltdl.m4 (AC_LTDL_SYS_DLOPEN_DEPLIBS): fill in yes for + recent Digital/Tru64 UNIX and IRIX. + ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
question about AC_LTDL_SYS_DLOPEN_DEPLIBS
I'm not 100% sure I know what whether deplibs are loaded by dlopen means. Does it mean: If you explicitly load a shared object via dlopen(), are any shared objects that it depends on loaded for you automatically? Or am I misinterpreting? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4b bootstrap nit
In regard to: Re: libtool-1.4b bootstrap nit, Gary V. Vaughan said (at...: On Wednesday 11 July 2001 1:17 am, Tim Mooney wrote: If I grab the tarball from alpha.gnu.org and untar it and then ./bootstrap No need to bootstrap it yourself unless you fetch from CVS. The tarballs we release are all pre-bootstrapped with a suitable version of autoconf and automake. Understood, but it should work. The reason I was doing it is that I eventually plan to apply a couple local patches to libtool, and they will require that some of the configure machinery be rebuilt. bootstrap is the easiest way to do that. The problem I'm seeing happens even without any local patches, though. ./configure gmake Don't forget that the make process is recursive, so you also need to `export MAKE=gmake' for the submakes to be called correctly. Thanks for the reminder, but that's not it either. it starts out by doing a recheck: /bin/ksh ./config.status --recheck Perhaps there is a broken macro in autoconf or libtool with respect to ksh? See below. In fact, I don't even need to rebuild configure to see the problem -- Just untarring libtool and running configure causes it to happen. Sorry I didn't notice that before. Can you retry with bash as the CONFIG_SHELL and see if that works? Doesn't make a difference -- though /bin/ksh is still used for the config.status re-runs. and I eventually see: configure: creating libtool appending configuration tag CXX to libtool checking whether the cxx linker (/usr/bin/ld) supports shared libraries... yes ./configure[7903]: syntax error at line 1 : `COPYING' unexpected Alphabetically, COPYING and Makefile are exactly the second files in their respective directories, which makes me think that the quoting in the new tags code is not robust to the version of ksh you are running... or possibly the version of /bin/sh configure re-execs itself with. If you can prove this somehow, we might be able to beat out a workaround for the next release. I did some more digging. The problem is coming from the output_verbose_link_cmd for alpha-dec-osf5.x (the osf4* | osf5* case) The whole thing is being eval'ed, and apparently the *) for the catchall case is therefore being globbed, which results in a list containing all the files in the current directory. It doesn't know how to parse anything beyond the first one, so the shell complains about it. If I had to guess, I would bet that any platform where the same output_verbose_link_cmd is used would cause the same problem. Looking at some of the other code in libtool.m4, you might be able to reproduce it on Linux if you use the Compaq cxx compiler, but I don't even know if that's available for Linux/Intel yet, so you would probably still need an alpha. You could probably just test that bit of code by making it the output_verbose_link_cmd for whatever CXX compiler you are using, to see if it does the same thing there. It's not the Right Thing for other compilers, but it would allow you to test the code itself, to see if you can reproduce the problem. And just to double check (note that the `a' suffix on the version numbers is because I have slightly newer than release versions built from CVS -- I hope that small difference isn't why you have errors though): I tried it with autoconf 2.50b, and it also doesn't make any difference. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4b bootstrap nit
In regard to: Re: libtool-1.4b bootstrap nit, Gary V. Vaughan said (at...: Excellent bug report Tim! Although unable to reproduce the bug with my shells, I have committed the attached patch, which I think will fix the problem for you. Thanks, that did fix it. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4 README patch
With these two items from the announcement: * Improved support for darwin (rhapsody), mingw32, NetBSD, Compaq Tru64 V5.0 and Digital Unix V4.*. ... * Support for aix5*. and my understanding of the very recent changes related to AIX (including AIX 5), coupled with the version numbering that is apparently going to be used on the next autoconf release, I think the libtool README might benefit from the following patch. Are the suggested changes all correct? diff -ur libtool-1.4.orig/README libtool-1.4/README --- libtool-1.4.orig/README Wed Dec 13 20:53:45 2000 +++ libtool-1.4/README Thu Apr 26 16:55:48 2001 @@ -17,10 +17,10 @@ Libtool supports building static libraries on all platforms. Shared library support has been implemented for these platforms: - AIX 3.x, 4.x (*-*-aix3*, *-*-aix4*) + AIX 3.x, 4.x, 5.x (*-*-aix3*, *-*-aix4*, *-*-aix5*) BeOS (*-*-beos*) BSD/OS 2.1, 3.x, 4.x (*-*-bsdi2.1, *-*-bsdi3*, *-*-bsdi4*) - Digital/UNIX 3.x, 4.x, a.k.a. OSF/1 (*-*-osf3*, *-*-osf4*) + Digital/Tru64 UNIX, a.k.a. OSF/1 3.x, 4.x, 5.x (*-*-osf[345]*) DG/UX R4.11, R4.12, R4.20 (*-*-dguxR411*, *-*-dguxR412*, *-*-dguxR420*) FreeBSD 2.x, 3.x, 4.x (*-*-freebsd2*, *-*-freebsd3*, *-*-freebsd4*) GNU Hurd (*-*-gnu*) @@ -52,7 +52,7 @@ workaround is to specify CC when run configure with CC='cc -Hnocopyr'. NOTE: Due to a bug in autoconf cc isn't supported on Motorola System V 4. -You can only use gcc. This bug will hopefully be fixed in autoconf 2.14. +You can only use gcc. This bug will hopefully be fixed in autoconf 2.50. NOTE: Any earlier DG/UX system with ELF executables, such as R3.10 or R4.10, is also likely to work, but hasn't been explicitly tested. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.910) test results for alpha-dec-osf4.0f (PASS)
In regard to: 1.3e (1.910) test results for alpha-dec-osf4.0f (PASS), Russ...: There were some warnings during some of the tests, though. Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... alpha-dec-osf4.0f checking build system type... alpha-dec-osf4.0f Using vendor ld and gcc 2.95.3. I get the same thing (including the same complaints from the loader) on alpha-dec-osf4.0f alpha-dec-osf5.1 both using vendor cc and ld. Note that you *must* make sure GNU make is in your PATH before the system make. Even doing something like gmake check (to cause GNU make to be used in the top level directory) will cause as many as 28 of the tests to fail. As soon as I did PATH=/local/gnu/bin:$PATH export PATH gmake check all tests passed. Wouldn't it be a win to add MAKE=$(MAKE) to the TESTS_ENVIRONMENT in tests/Makefile.am, so we're certain that all the *.test scripts get the same make that was used in the top level directory? With that change in place, using gmake check now works. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Porting question (HP-UX on IA64)
In regard to: Porting question (HP-UX on IA64), Steve Ellcey said (at...: So my question is: how do I deal with this in libtool? Specifically I am trying to set sys_lib_search_path_spec and sys_lib_dlsearch_path_spec to different values based on what I am trying to link. It would be nice if I could do what HP's ld does and just look at the first object to see what it is (file would tell me if it was 32 or 64 bits), if that isn't possible then I could look for an option (say the -milp32 or -mlp64 options that are used for gcc) to set sys_lib_search_path_spec. But I am not sure how to do either. Can someone offer advice or an example on how this is done? You could look at the stuff in libtool for IRIX, specifically 6.x. IRIX does this in a very similar fashion (/usr/lib, /usr/lib32, /usr/lib64, etc) for the three ABIs on recent IRIX. I'm looking at ltconfig for libtool 1.3.5, even that far back there was good support for doing what you're trying to do. Search for libsuff in ltconfig from 1.3.5, to find the section I'm talking about. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool on solaris and hard coding the rpath
In regard to: libtool on solaris and hard coding the rpath, Liam Hoekenga...: % ldd libphp4.so libpam.so.1 = /usr/lib/libpam.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libresolv.so.2 =/usr/lib/libresolv.so.2 libm.so.1 = /usr/lib/libm.so.1 libclntsh.so.8.0 = (file not found) libc.so.1 = /usr/lib/libc.so.1 libmp.so.2 =/usr/lib/libmp.so.2 Is there any way to actually get libtool (on Solaris) to hardcode the rpath into shared libraries (in addition to any program binaries it might be used to generate)? I'm not sure what the libtool maintainers policy on this particular issue is, but I've always preferred to have the RPATH hardcoded into libraries as well, especially on platforms like Tru64 UNIX and IRIX, where the apps automatically pick up that RPATH when they link with the library (so you don't need to worry about specifying an RPATH when you link the app, only when you build the libraries). Solaris is a bit more of a pain, but that's Solaris. :-) I have a patch that really saves me some work with Tru64 and IRIX, but I'm not sure it wins me anything on Solaris, since even if you build a DT_RPATH into a library there, the apps generally don't pick it up from the library. You do know about the LD_RUN_PATH environment variable that the Solaris linker will honor, though, right? You could use that to hardcode your DT_RPATH with `libtool' being none the wiser, I think. Tim ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dlopen on Solaris compared with IRIX/Tru64
In regard to: Re: dlopen on Solaris compared with IRIX/Tru64, Albert...: Not all systems allow you to embed RPATH in a library. Tru64 UNIX 4.0D is one. I think libtool 1.4 and above allow you to embed RPATH. Unless I misunderstand you, that's not correct: 05:04pm obelisk lib$odump -D /local/lib/libz.so | egrep 'RPATH' RPATH: /local/lib 05:05pm obelisk lib$sizer -v Digital UNIX V4.0D (Rev. 878); Mon Mar 13 16:49:14 CST 2000 I've been doing this successfully for a long time. What *is* true, in the context of the original topic, is that at least through 5.0 the RPATH in a shared library is not used to find shared libraries that are explictly dlopened by a program. I had a Compaq loader engineer explain it to me one time, it's somewhat complex. They expect to change that behavior in the future, from what he said. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX 4.3 and cvs libtool
In regard to: AIX 4.3 and cvs libtool, Kevin Ryde said (at 6:58am on Nov...:
gcc -shared -o .libs/libfoo.so.3.1.0 foo.o -Wl,-bexpall \
-Wl,-bnoentry ${wl}-berok
I think the literal ${wl} might be too much quoting or not enough
evaling of $allow_undefined_flag. (And glancing at libtool.m4, the
same might apply on osf[345].)
I believe you're right. I've run into the same problem at various times
with libtool my our Digital/Tru64 UNIX boxes (4.x and 5.x).
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
