Re: Alternate SONAME values
Hi Keith, others,
Sorry for the response latency. This is a status update for the -sobase
patch: http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html.
* Keith Packard wrote on Mon, Jul 11, 2005 at 09:55:47PM CEST:
On Mon, 2005-07-11 at 13:58 +0200, Ralf Wildenhues wrote:
Re-reading this thread, I would be inclined to accept a patch which
implements your original proposal, given that a way can be found how it
degrades gracefully on the different/not-so-flexible shared library
systems mentioned. That is, unless the other maintainers oppose.
Ok, I've created a '-sobase' option in link mode and tested it on
GNU/Linux. It changes the -soname option passed to the linker so that
instead of using ${libname} for the first part of the soname, it uses
the -sobase parameter. It also includes this generated name as one of
the library_names so that when the library is installed, a symlink to
the soname is made.
Hmm. I've started a test suite test to go along with this, so that we
can actually make sure this works as expected, and also do not
gratuitously break installed .la files and linking against them.
I am a little stuck, however. Maybe someone else can provide input
(be sure to read all the way to the AIX case, however):
Your patch changes library_names in the .la file to also include a name
for the different sobase. You don't, however, add the unversioned name,
thus the unversioned link also is not generated. Isn't this what you
wanted instead? (see also in the test below)
Furthermore, libtool expects the last name in library_names to be the
unversioned name, i.e., the one to link against. The deplib search code
needs adjusting to this (basically the places where library_names is
read from an already-written .la file).
I believe this is the reason that the test currently fails (on linux,
solaris) because it forgets to put the rpath information in
main_static, in case we link against the lib which links against the
-sobase-treated lib: Libtool does not walk its dependency chain.
I haven't completely checked either that libtool implicitly assumes that
the base name of all words in $library_names is the same.
We /might/ be able to limit ourselves to allowing just one of the names
to link to. In any case, the way the result works still needs to be
documented.
Tested on: GNU/Linux/x86_64, Solaris/{gcc,Sun cc}/Solaris ld.
AIX is a completely different matter yet: it can have dynamic archives
ending in .a (with soname ending in .so). Here, your patch breaks
already while creating libtestB.la -- we can't mix the library names
and soname concepts so easily here (As a followup error, the test
seems to bogusly cause removal of the uninstalled .la files -- bad).
I have not tested win32 nor Darwin yet, but expect them to be on a
similar fun level as AIX. (As a minor detail, the test, being
unfinished, is also missing proper initialization for some tools).
Cheers,
Ralf
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.155
diff -u -r1.155 Makefile.am
--- Makefile.am 8 Aug 2005 09:23:57 - 1.155
+++ Makefile.am 9 Aug 2005 07:43:42 -
@@ -301,6 +301,7 @@
tests/stresstest.at \
tests/link-order.at \
tests/convenience.at \
+ tests/sobase.at \
tests/template.at
EXTRA_DIST += $(TESTSUITE) $(TESTSUITE_AT) tests/package.m4
Index: tests/testsuite.at
===
RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v
retrieving revision 1.15
diff -u -r1.15 testsuite.at
--- tests/testsuite.at 30 Apr 2005 09:30:14 - 1.15
+++ tests/testsuite.at 9 Aug 2005 07:43:42 -
@@ -93,6 +93,8 @@
m4_include([convenience.at])
# link order test
m4_include([link-order.at])
+# sobase test
+m4_include([sobase.at])
# Torturing subdir-objects builds
m4_include([am-subdir.at])
# C++ templates tests
--- /dev/null 2005-08-03 12:45:51.659987528 +0200
+++ tests/sobase.at 2005-08-09 07:39:29.0 +0200
@@ -0,0 +1,90 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2005 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor,
Re: Alternate SONAME values
On Tue, 2005-08-09 at 15:13 +0200, Ralf Wildenhues wrote: Hi Keith, others, Sorry for the response latency. This is a status update for the -sobase patch: http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html. Thanks for your response and your work on this matter. Your patch changes library_names in the .la file to also include a name for the different sobase. You don't, however, add the unversioned name, thus the unversioned link also is not generated. Isn't this what you wanted instead? (see also in the test below) No, the alternate name is strictly for run-time linking, not compile time library detection. In particular, I'm installing three libraries with the same unversioned name (libXaw.so), so I really *can't* have them install the unversioned name. At compile time, I expect applications to use the 'standard' library name (libXaw6.so, libXaw7.so or libXaw8.so). Furthermore, libtool expects the last name in library_names to be the unversioned name, i.e., the one to link against. The deplib search code needs adjusting to this (basically the places where library_names is read from an already-written .la file). Ah, I never install .la files, so I wouldn't have caught this regression. I suggest that the better fix would be to place the new names earlier in the library_names list. Would that solve the problem here? We /might/ be able to limit ourselves to allowing just one of the names to link to. In any case, the way the result works still needs to be documented. I don't need to permit linking against the alternate name, only against the official name. AIX is a completely different matter yet: it can have dynamic archives ending in .a (with soname ending in .so). Here, your patch breaks already while creating libtestB.la -- we can't mix the library names and soname concepts so easily here (As a followup error, the test seems to bogusly cause removal of the uninstalled .la files -- bad). The question is whether this hack is needed at all on these systems. What I need to do is take an existing application, linked with a specific version of Xaw referenced by '-lXaw' to find the right library. On ELF systems, this means setting the .soname in the library correctly; I don't know what it means for non-ELF systems; it could be as easy as just creating symlinks to the library with the right names. So, what the test should do is build the library with the old name (libXaw.la), link an application and then build the library with the new name (libXaw7.la) and the -sobase option set to libXaw and make sure the application continues to run. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi Keith, * Keith Packard wrote on Fri, Jul 08, 2005 at 11:42:57PM CEST: On Fri, 2005-07-08 at 11:23 +0200, Simon Richter wrote: Now I'm wondering whether it would make sense to add a switch to libtool that makes it not install those two things, such as -old-abi. I have to support two of these library versions as 'current' for other reasons, so applications need to be able to link against either libXaw7 or libXaw8 at build time, so I need two unversioned .so files... *snip* Yes, there are probably too many constraints on the solution space. Re-reading this thread, I would be inclined to accept a patch which implements your original proposal, given that a way can be found how it degrades gracefully on the different/not-so-flexible shared library systems mentioned. That is, unless the other maintainers oppose. (I personally won't there to review it for a while though, sorry.) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Mon, 2005-07-11 at 13:58 +0200, Ralf Wildenhues wrote:
Re-reading this thread, I would be inclined to accept a patch which
implements your original proposal, given that a way can be found how it
degrades gracefully on the different/not-so-flexible shared library
systems mentioned. That is, unless the other maintainers oppose.
Ok, I've created a '-sobase' option in link mode and tested it on
GNU/Linux. It changes the -soname option passed to the linker so that
instead of using ${libname} for the first part of the soname, it uses
the -sobase parameter. It also includes this generated name as one of
the library_names so that when the library is installed, a symlink to
the soname
is made.
-keith
Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.73
diff -u -p -r1.73 ltmain.m4sh
--- config/ltmain.m4sh 8 Jul 2005 13:45:59 - 1.73
+++ config/ltmain.m4sh 11 Jul 2005 19:25:05 -
@@ -348,6 +348,7 @@ The following components of LINK-COMMAND
-R[[ ]]LIBDIR add LIBDIR to the runtime path of programs and libraries
-shared only do dynamic linking of libtool libraries
-shrext SUFFIXoverride the standard shared library file extension
+ -sobase SOBASESet base of SONAME to SOBASE instead of LIBNAME
-static do not do any dynamic linking of libtool libraries
-version-info CURRENT[[:REVISION[:AGE]]]
specify library version info [[each variable defaults to 0]]
@@ -2484,6 +2485,13 @@ func_mode_link ()
prev=
continue
;;
+ sobase)
+ sobase_name=$arg
+ solib_names_spec=$soname_spec
+ prev=
+ continue
+ ;;
+
weak)
weak_libs=$weak_libs $arg
prev=
@@ -2760,6 +2768,11 @@ func_mode_link ()
continue
;;
+ -sobase)
+prev=sobase
+ continue
+ ;;
+
-static)
# The effects of -static are defined in a previous loop.
# We used to do the same as -all-static on platforms that
@@ -3703,6 +3716,9 @@ func_mode_link ()
realname=$1
shift
libname=`eval \\$ECHO \$libname_spec\`
+ if test -z $sobase_name; then
+ sobase_name=$libname
+ fi
# use dlname if we got it. it's perfectly good, no?
if test -n $dlname; then
soname=$dlname
@@ -4610,7 +4626,7 @@ EOF
fi
if test -n $i ; then
libname=`eval \\$ECHO \$libname_spec\`
- deplib_matches=`eval \\$ECHO \$library_names_spec\`
+ deplib_matches=`eval \\$ECHO \$library_names_spec $solib_names_spec\`
set dummy $deplib_matches; shift
deplib_match=$1
if test `expr $ldd_output : .*$deplib_match` -ne 0 ; then
@@ -4652,7 +4668,7 @@ EOF
fi
if test -n $i ; then
libname=`eval \\$ECHO \$libname_spec\`
- deplib_matches=`eval \\$ECHO \$library_names_spec\`
+ deplib_matches=`eval \\$ECHO \$library_names_spec $solib_names_spec\`
set dummy $deplib_matches; shift
deplib_match=$1
if test `expr $ldd_output : .*$deplib_match` -ne 0 ; then
@@ -4960,12 +4976,15 @@ EOF
# Get the real and link names of the library.
eval shared_ext=\$shrext_cmds\
- eval library_names=\$library_names_spec\
+ eval library_names=\$library_names_spec $solib_names_spec\
set dummy $library_names
shift
realname=$1
shift
+ if test -z $sobase_name; then
+ sobase_name=$libname
+ fi
if test -n $soname_spec; then
eval soname=\$soname_spec\
else
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.203
diff -u -p -r1.203 libtool.m4
--- m4/libtool.m4 11 Jul 2005 12:11:25 - 1.203
+++ m4/libtool.m4 11 Jul 2005 19:25:07 -
@@ -1745,7 +1745,7 @@ aix3*)
shlibpath_var=LIBPATH
# AIX 3 has no versioning support, so we append a major version to the name.
- soname_spec='${libname}${release}${shared_ext}$major'
+ soname_spec='${sobase_name}${release}${shared_ext}$major'
;;
aix4* | aix5*)
@@ -1786,7 +1786,7 @@ aix4* | aix5*)
# We preserve .a as extension for shared libraries through AIX4.2
# and later when we are not doing run time linking.
library_names_spec='${libname}${release}.a $libname.a'
- soname_spec='${libname}${release}${shared_ext}$major'
+ soname_spec='${sobase_name}${release}${shared_ext}$major'
fi
shlibpath_var=LIBPATH
fi
@@ -1812,7 +1812,7 @@ bsdi[[45]]*)
version_type=linux
need_version=no
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
+ soname_spec='${sobase_name}${release}${shared_ext}$major'
finish_cmds='PATH=\$PATH:/sbin ldconfig $libdir'
shlibpath_var=LD_LIBRARY_PATH
sys_lib_search_path_spec=/shlib /usr/lib /usr/X11/lib /usr/contrib/lib /lib /usr/local/lib
@@ -1849,12 +1849,12 @@ cygwin* | mingw* | pw32*)
case $host_os in
Re: Alternate SONAME values
Hi Keith, * Keith Packard wrote on Fri, Jul 08, 2005 at 06:59:10AM CEST: On Fri, 2005-07-08 at 09:24 +0530, Ganesan Rajagopal wrote: But libXaw.so.major_number is the default behaviour for libtool. Are you using -release instead of -version-info or -version-number? I think -version-number will give you exactly what you need. I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so And, yes, I'm already using -version-number (which I added to libtool) as X has always used the same version number on all platforms (yes, this is bad, but I can't do anything about it). I have thought a little bit about this, quite a bit of open questions still, before I can allow myself an informed opinion about this. (I'll freely admit that you probably know more about the topic than I do. :) First, to stay with your GNU/Linux example, unless you also have libXaw.so.6 as symlink, how will ld.so find your library (as installed library; or alternatively as user-installed test version below $HOME)? Second, have you tried this on a different system? Especially for AIX (without runtime linking) Darwin w32 (cygwin/mingw) I don't know off the head whether this could be made to work. Next, what is the general rule for applications which may use libraries that link against different Xaw major versions? Here, big trouble may ensue. It sounds like you don't want to encourage this anyway, but I'm not certain. (Carrying this on and allowing other libs several major versions installed, you may end up with libraries libfoo6-bar2-Xaw7, since the dependent libraries have to carry over that versioning.) Last, I do believe that if Libtool were to allow this, it might have to adapt its deplib search algorithm as well, at least on some systems. This in turn should avoid backwards-incompatibility (i.e., older libtool versions not being able to link against the libs created by newer libtool). Haven't thought about this in detail yet, but I'd really like to avoid breaking applications that depend on libXaw* and happen to use (an older version of) libtool, if possible. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Keith == Keith Packard [EMAIL PROTECTED] writes: On Fri, 2005-07-08 at 09:24 +0530, Ganesan Rajagopal wrote: But libXaw.so.major_number is the default behaviour for libtool. Are you using -release instead of -version-info or -version-number? I think -version-number will give you exactly what you need. I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so Sorry, my bad. I completely misunderstood your question. For some stupid reason I kept seeing libXaw.so.6 instead of libXaw6.so.6. I should've read your mail more carefully. I apologize for attempting to educate you on things that you obviously already know! I don't know a solution to your problem, but now that I have actually understood your mail fully, let me go back and respond to it. May be this time, I'll respond more intelligently :-) And, yes, I'm already using -version-number (which I added to libtool) I knew you're the X Window System Guru, but didn't realize you dug into libtool internals too! Oops, sorry to be preaching to the master :-). Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 08:31 +0200, Ralf Wildenhues wrote: First, to stay with your GNU/Linux example, unless you also have libXaw.so.6 as symlink, how will ld.so find your library (as installed library; or alternatively as user-installed test version below $HOME)? The current ELF shared library mechanism in glibc uses SONAMEs exclusively when locating libraries. The filename is irrelevant. Second, have you tried this on a different system? Especially for AIX (without runtime linking) Darwin w32 (cygwin/mingw) No, I haven't. I have little experience with these systems, so I don't even know if this scheme will work. Hence my question to this list where I imagine there are people with experience on those systems. The key question is whether the system uses SONAMES or filenames to locate libraries. I don't know off the head whether this could be made to work. Next, what is the general rule for applications which may use libraries that link against different Xaw major versions? You're SOL. The different versions all share the same symbol names. Fortunately, this doesn't happen in practice as you don't generally find libraries using Xaw in the wild. And, of course, we actively discourage anyone from using any version of Xaw; it's a terrible library. Here, big trouble may ensue. It sounds like you don't want to encourage this anyway, but I'm not certain. (Carrying this on and allowing other libs several major versions installed, you may end up with libraries libfoo6-bar2-Xaw7, since the dependent libraries have to carry over that versioning.) Last, I do believe that if Libtool were to allow this, it might have to adapt its deplib search algorithm as well I don't care about this; I remove all .la files on my system as they are only trouble. Of course, this breaks any application using libltdl, but so far that hasn't been a big deal. I consider this latter a bug in ltdl and not a reason to install .la files. I have local hacks for libtool which prevent the .la files from being installed in the first place, which has certainly saved me a lot of pain as I constantly move libraries around on my system. , at least on some systems. This in turn should avoid backwards-incompatibility (i.e., older libtool versions not being able to link against the libs created by newer libtool). Haven't thought about this in detail yet, but I'd really like to avoid breaking applications that depend on libXaw* and happen to use (an older version of) libtool, if possible. As long as you have no .la files, there's no problem as the libtool search mechanisms are not used. So, the fix here is to just not install any of the libXaw*.la files. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Russ == Russ Allbery [EMAIL PROTECTED] writes: Ganesan Rajagopal [EMAIL PROTECTED] writes: I didn't know this. But trying to make -version-info get the SONAME you need is an abuse of libtool in any case. I think -version-number option available in recent versions of libtool is perfect for this. When introducing libtool with a libraries like X that have a well-established SONAME, one does not get to change the SONAME just because new applications using libtool shouldn't try to override the SONAME. It may be libtool abuse in a new application with no established library versioning, but for X, it's the difference between a working build system and a broken build system. Please re-read what I said :-). Using -version-info (note that this is a different option) to get the SONAME correct is an abuse of libtool because you can't expect it to work reliably. However, using -version-number is not an abuse, it's available for exactly this reason. Once again from the libtool manual === `-version-number MAJOR[:MINOR[:REVISION]]' If OUTPUT-FILE is a libtool library, compute interface version information so that the resulting library uses the specified major, minor and revision numbers. This is designed to permit libtool to be used with existing projects where identical version numbers are already used across operating systems. New projects should use the `-version-info' flag instead. === There are ten-year-old binaries that expect a particular SONAME for the X libraries and can't simply be rebuilt. It's very, very important that they not break. We're very much in agreement :-). Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Keith == Keith Packard [EMAIL PROTECTED] writes: No, I haven't. I have little experience with these systems, so I don't even know if this scheme will work. Hence my question to this list where I imagine there are people with experience on those systems. The key question is whether the system uses SONAMES or filenames to locate libraries. Even if they do use file names to locate libraries, can't you continue to additionaly ship filenames matching the SONAMES? I mean having a symlink libXaw.so.6.0.0 - libXaw6.so.6.0.0. In fact, thinking further about the scenario you presented with version-less file names: === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6 Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7 Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw.so === Can't you just manually create and ship versioned .so file names? Like === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6, libXaw6.so Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7, libXaw7.so Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw8.so, libXaw.so === You need to create libXaw6.so - libXaw.so.6 links manually after libtool. This seems to be a simpler approach to tweaking the SONAMEs that libtool generates. Of course, I might still be missing something here, so I'll stop with this mail :-). And, of course, we actively discourage anyone from using any version of Xaw; it's a terrible library. Then why make this any easier ;-). What's wrong with the current scheme of not shipping .so symlinks with the library but shipping them in a -dev package, one for each library major version? The -dev packages do conflict with each other. This already makes it possible, if not easy, to link to older libraries for some one who really cares. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi, Keith Packard wrote: I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so There is no need to name the real file libXaw6.so.6.0.1, as the 6 is mentioned twice this way (libXaw.so.6.0.1 suffices). The unversioned symlink and the .la file are the only things that conflict between versions; I'd think that there is some sort of a current ABI which would get its symlink/.la installed. Now I'm wondering whether it would make sense to add a switch to libtool that makes it not install those two things, such as -old-abi. Simon ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Hi Keith, * Keith Packard wrote on Fri, Jul 08, 2005 at 08:47:37AM CEST: On Fri, 2005-07-08 at 08:31 +0200, Ralf Wildenhues wrote: First, to stay with your GNU/Linux example, unless you also have libXaw.so.6 as symlink, how will ld.so find your library (as installed library; or alternatively as user-installed test version below $HOME)? The current ELF shared library mechanism in glibc uses SONAMEs exclusively when locating libraries. The filename is irrelevant. No. If a DSO with matching SONAME is already mapped, ld.so is done. If not, it searches for a library with a file name which matches the SONAME, unless the SONAME - file name pair is listed in /etc/ld.so.cache. That's why I asked how you would work with uninstalled or user-installed (for testing) libraries. Please note that ldconfig -n sets the appropriate symlinks which contain the SONAMEd file name if not present. So, you'd end up with libXaw6.la, and libXaw6.so.6.0.1 libXaw6.so.6 libXaw6.so libXaw.so.6 all pointing to the same file. I might still have completely misunderstood you here -- please correct me if I'm wrong. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
* Ralf Wildenhues wrote on Fri, Jul 08, 2005 at 04:15:53PM CEST: Keith, could you confirm that this would be enough for your needs, when given as install mode switch? Current idea would be to have it install the first name from library_names only, do not delete the symlinks nor s/the first name/all but the last name, in case there are several names/ create new ones, do not install the .la file. Sorry, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 14:10 +0530, Ganesan Rajagopal wrote: Keith == Keith Packard [EMAIL PROTECTED] writes: No, I haven't. I have little experience with these systems, so I don't even know if this scheme will work. Hence my question to this list where I imagine there are people with experience on those systems. The key question is whether the system uses SONAMES or filenames to locate libraries. Even if they do use file names to locate libraries, can't you continue to additionaly ship filenames matching the SONAMES? I mean having a symlink libXaw.so.6.0.0 - libXaw6.so.6.0.0. Yes, that is one possibility. It complicates the install process as libtool always wants to install the bare .so version of the file (libXaw.so), and this would give us three potential versions of that file, depending on which library you happened to install last. Plus, it means I can use automake to construct these libraries in the same directory, which is obviously not a huge deal. There are also packaging systems which dislike having multiple major versions of the same library installed at the same time. Gtk+, in particular, appends '-2.0' to every library name precisely to avoid this particular issue. We wanted to take advantage of distinct filenames for all packages. In fact, thinking further about the scenario you presented with version-less file names: === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6 Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7 Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw.so === Can't you just manually create and ship versioned .so file names? Like === Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6, libXaw6.so Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7, libXaw7.so Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw8.so, libXaw.so === You need to create libXaw6.so - libXaw.so.6 links manually after libtool. This seems to be a simpler approach to tweaking the SONAMEs that libtool generates. Of course, I might still be missing something here, so I'll stop with this mail :-). This is actually harder than it seems as I wouldn't be able to use libtool to install the library, and automake really doesn't want you to avoid that. I can't fix things up after the fact as the bare libXaw.so would be trashed by the libtool install step. And, of course, we actively discourage anyone from using any version of Xaw; it's a terrible library. Then why make this any easier ;-). What's wrong with the current scheme of not shipping .so symlinks with the library but shipping them in a -dev package, one for each library major version? The install process for the packages isn't really a problem; rather it's the automake install process which doesn't provide this distinction. The -dev packages do conflict with each other. This already makes it possible, if not easy, to link to older libraries for some one who really cares. Sure, but some packging systems (RPM?) don't even like run-time packages to share the same library name with different major so versions. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 14:07 +0200, Ralf Wildenhues wrote: No. If a DSO with matching SONAME is already mapped, ld.so is done. If not, it searches for a library with a file name which matches the SONAME, unless the SONAME - file name pair is listed in /etc/ld.so.cache. Sure, but the SONAME still has to be right, so I can't build libXaw6.so.6.0.1 with SONAME libXaw6.so.6, symlink it to libXaw.so.6 and expect applications asking for libXaw.so.6 to work. Which means that with current libtool, I must ask it to build libXaw.so.6 and then link that to libXaw6.so.6, which I also can't do as that will trash any libXaw.so when libtool installs the library. I don't mind getting libtool to build libXaw.so.6, but I can't ask libtool to *install* a libXaw.la that points at that file. Thanks for reminding me that the filename is still relevant for libraries not in ld.so.cache; I'll have to make sure I create the links at install time. Of course, if we do hack libtool to support alternate SONAME values, we could also hack it to manage these symlinks for us. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 16:15 +0200, Ralf Wildenhues wrote: Keith, could you confirm that this would be enough for your needs, when given as install mode switch? Current idea would be to have it install the first name from library_names only, do not delete the symlinks nor create new ones, do not install the .la file. As mentioned previously, I actually do need multiple unversioned .so files installed at the same time... Or do you also need to prevent creating the symlinks in the build tree (below $builddir/.libs/), maybe because you actually build all three library major versions in the same directory? Then we'd need to do something at link mode. Oh, I don't care about this; I can construct parallel directories if necessary (there actually were parallel directories a few days ago as the library was autotooled by people unfamiliar with the *_la_CFLAGS behaviour of automake) -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 11:23 +0200, Simon Richter wrote: Now I'm wondering whether it would make sense to add a switch to libtool that makes it not install those two things, such as -old-abi. I have to support two of these library versions as 'current' for other reasons, so applications need to be able to link against either libXaw7 or libXaw8 at build time, so I need two unversioned .so files... You see, libXaw8 includes XPrint support, which is not universally loved by the X community, so applications not interested in printing shoud link against libXaw7 as libXaw8 is not present on most Linux systems. Yes, there are probably too many constraints on the solution space. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Alternate SONAME values
I'm building a weird set of libraries and would like libtool to help out a bit by providing some mechanism to modify the SONAME placed into the .so file. X has three versions of the Xaw library; version 6, 7 and 8 (cooresponding to the .so major version numbers, which are the same across all supported X platforms). Unfortunately, we want to be able to install all three at the same time, and permit applications to select which to link against. To make this possible on the widest range of platforms, this means that we should really use different filenames for the various libraries: Version 6 Xaw - libXaw6.so.6.0.1, libXaw6.so.6, libXaw6.so Version 7 Xaw - libXaw7.so.7.0.0, libXaw7.so.7, libXaw7.so Version 8 Xaw - libXaw8.so.8.0.0, libXaw8.so.8, libXaw8.so These are obviously easy enough to generate with libtool, and I've done so. However, I have an additional constraint -- existing applications using these libraries must continue to operate normally. These existing applications use version-less filenames: Version 6 Xaw - libXaw.so.6.0.1, libXaw.so.6 Version 7 Xaw - libXaw.so.7.0.0, libXaw.so.7 Version 8 Xaw - libXaw.so.8.0.0, libXaw.so.8, libXaw.so We could use these same filenames again, but you'll note that only one version can link to the bare .so name, leaving applications at the mercy of the system to decide which version of the library they will use. There is another way to solve the problem; we can change the SONAME in the versioned filename varients: Version 6 Xaw - libXaw6.so.6.0.1 SONAME=libXaw.so.6 Version 7 Xaw - libXaw7.so.7.0.0 SONAME=libXaw.so.7 Version 8 Xaw - libXaw8.so.8.0.0 SONAME=libXaw.so.8 With this setup, existing applications will find the right library, and new applications will be able to select the appropriate version to link against. The help I need from libtool is to permit me to change the 'libname' placed into the SONAME of the library at link time. Is there a better way of solving this problem? Or is my plan something that would be acceptable in a distributed version of libtool? If so, I'll send a patch. -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Keith == Keith Packard [EMAIL PROTECTED] writes: There is another way to solve the problem; we can change the SONAME in the versioned filename varients: Version 6 Xaw - libXaw6.so.6.0.1 SONAME=libXaw.so.6 Version 7 Xaw - libXaw7.so.7.0.0 SONAME=libXaw.so.7 Version 8 Xaw - libXaw8.so.8.0.0 SONAME=libXaw.so.8 May be I am missing something here. Assuming you used -version-info to generate the libraries, libtool embeds the library SONAME with the major version into the library by default. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Thu, Jul 07, 2005 at 03:53:17PM +0530, Ganesan Rajagopal wrote: Keith == Keith Packard [EMAIL PROTECTED] writes: There is another way to solve the problem; we can change the SONAME in the versioned filename varients: Version 6 Xaw - libXaw6.so.6.0.1 SONAME=libXaw.so.6 Version 7 Xaw - libXaw7.so.7.0.0 SONAME=libXaw.so.7 Version 8 Xaw - libXaw8.so.8.0.0 SONAME=libXaw.so.8 May be I am missing something here. Assuming you used -version-info to generate the libraries, libtool embeds the library SONAME with the major version into the library by default. But libtool does not compute the SONAME across all platforms the same. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Thu, 2005-07-07 at 15:53 +0530, Ganesan Rajagopal wrote:
Keith == Keith Packard [EMAIL PROTECTED] writes:
There is another way to solve the problem; we can change the SONAME in
the versioned filename varients:
Version 6 Xaw - libXaw6.so.6.0.1 SONAME=libXaw.so.6
Version 7 Xaw - libXaw7.so.7.0.0 SONAME=libXaw.so.7
Version 8 Xaw - libXaw8.so.8.0.0 SONAME=libXaw.so.8
May be I am missing something here. Assuming you used -version-info to
generate the libraries, libtool embeds the library SONAME with the major
version into the library by default.
I want to change the base of the SONAME from libXaw6 to libXaw, and have
the major version only present after the .so; as far as I can tell, I
can't get libtool to do this.
I hacked libtool to set the base of the soname (which is normally
'${libname}' to libXaw and things are working correctly on Linux.
-keith
signature.asc
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Keith == Keith Packard [EMAIL PROTECTED] writes: On Thu, 2005-07-07 at 15:53 +0530, Ganesan Rajagopal wrote: Keith == Keith Packard [EMAIL PROTECTED] writes: There is another way to solve the problem; we can change the SONAME in the versioned filename varients: Version 6 Xaw - libXaw6.so.6.0.1 SONAME=libXaw.so.6 Version 7 Xaw - libXaw7.so.7.0.0 SONAME=libXaw.so.7 Version 8 Xaw - libXaw8.so.8.0.0 SONAME=libXaw.so.8 May be I am missing something here. Assuming you used -version-info to generate the libraries, libtool embeds the library SONAME with the major version into the library by default. I want to change the base of the SONAME from libXaw6 to libXaw, and have the major version only present after the .so; as far as I can tell, I can't get libtool to do this. But libXaw.so.major_number is the default behaviour for libtool. Are you using -release instead of -version-info or -version-number? I think -version-number will give you exactly what you need. `-version-number MAJOR[:MINOR[:REVISION]]' If OUTPUT-FILE is a libtool library, compute interface version information so that the resulting library uses the specified major, minor and revision numbers. This is designed to permit libtool to be used with existing projects where identical version numbers are already used across operating systems. New projects should use the `-version-info' flag instead. May be you're explicitly passing libXaw6.la as the library name instead of libXaw.la. You should pass libXaw.la as the library name instead of libXaw6.la or libXaw7.la. Let me give an example: $ touch xaw.c $ libtool --mode=link gcc -rpath /usr/lib -version-number 6:0:0 -o libXaw.la xaw.c rm -fr .libs/libXaw.a .libs/libXaw.la .libs/libXaw.lai .libs/libXaw.so .libs/libXaw.so.6 .libs/libXaw.so.6.0.1 gcc -shared-Wl,-soname -Wl,libXaw.so.6 -o .libs/libXaw.so.6.0.0 (cd .libs rm -f libXaw.so.6 ln -s libXaw.so.6.0.0 libXaw.so.6) (cd .libs rm -f libXaw.so ln -s libXaw.so.6.0.0 libXaw.so) ar cru .libs/libXaw.a ranlib .libs/libXaw.a creating libXaw.la (cd .libs rm -f libXaw.la ln -s ../libXaw.la libXaw.la) $ libtool --mode=link gcc -rpath /usr/lib -version-number 7:0:1 -o libXaw.la xaw.c rm -fr .libs/libXaw.a .libs/libXaw.la .libs/libXaw.lai .libs/libXaw.so .libs/libXaw.so.6 .libs/libXaw.so.6.0.0 gcc -shared-Wl,-soname -Wl,libXaw.so.7 -o .libs/libXaw.so.7.0.1 (cd .libs rm -f libXaw.so.7 ln -s libXaw.so.7.0.1 libXaw.so.7) (cd .libs rm -f libXaw.so ln -s libXaw.so.7.0.1 libXaw.so) ar cru .libs/libXaw.a ranlib .libs/libXaw.a creating libXaw.la (cd .libs rm -f libXaw.la ln -s ../libXaw.la libXaw.la) As you can see, The SONAME is libXaw.so.6 or libXaw.so.7 which is exactly what you want. By the way, I have libtool 1.5.6 on Debian. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Albert == Albert Chin [EMAIL PROTECTED] writes: On Thu, Jul 07, 2005 at 03:53:17PM +0530, Ganesan Rajagopal wrote: Keith == Keith Packard [EMAIL PROTECTED] writes: There is another way to solve the problem; we can change the SONAME in the versioned filename varients: Version 6 Xaw - libXaw6.so.6.0.1 SONAME=libXaw.so.6 Version 7 Xaw - libXaw7.so.7.0.0 SONAME=libXaw.so.7 Version 8 Xaw - libXaw8.so.8.0.0 SONAME=libXaw.so.8 May be I am missing something here. Assuming you used -version-info to generate the libraries, libtool embeds the library SONAME with the major version into the library by default. But libtool does not compute the SONAME across all platforms the same. I didn't know this. But trying to make -version-info get the SONAME you need is an abuse of libtool in any case. I think -version-number option available in recent versions of libtool is perfect for this. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
On Fri, 2005-07-08 at 09:24 +0530, Ganesan Rajagopal wrote: But libXaw.so.major_number is the default behaviour for libtool. Are you using -release instead of -version-info or -version-number? I think -version-number will give you exactly what you need. I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la, libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so And, yes, I'm already using -version-number (which I added to libtool) as X has always used the same version number on all platforms (yes, this is bad, but I can't do anything about it). -keith signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Alternate SONAME values
Ganesan Rajagopal [EMAIL PROTECTED] writes: I didn't know this. But trying to make -version-info get the SONAME you need is an abuse of libtool in any case. I think -version-number option available in recent versions of libtool is perfect for this. When introducing libtool with a libraries like X that have a well-established SONAME, one does not get to change the SONAME just because new applications using libtool shouldn't try to override the SONAME. It may be libtool abuse in a new application with no established library versioning, but for X, it's the difference between a working build system and a broken build system. There are ten-year-old binaries that expect a particular SONAME for the X libraries and can't simply be rebuilt. It's very, very important that they not break. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
