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
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
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
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
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
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
max_cmd_len in ltmain.sh
I'm having trouble understanding how max_cmd_len is supposed to be getting initialized in ltmain.sh so I can use libtoolize with my package. libtool has a nice assignment, but ltmain.sh contains only references to this variable. Am I supposed to perform additional magic on the ltmain.sh that libtoolize sticks in my directory? -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: max_cmd_len in ltmain.sh
Around 21 o'clock on Jul 20, Albert Chin wrote: It should be set in the generated 'libtool' program. Look at AC_LIBTOOL_SYS_MAX_CMD_LEN in libtool.m4. Yes, it's nicely set in the generated 'libtool' program that gets installed on my machine, but I want to use 'libtoolize --force --copy' in my package which dumps 'ltmain.sh' in the package directory; configure builds libtool from that. But, the generated libtool is then missing the definition of max_cmd_len. Am I missing something that I need to add to connfigure.ac? -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Migrating existing libraries to libtool
I maintain a few X libraries and would like to see about transitioning them from imake to automake. The stumbling block is that I cannot change the library version numbers across this transition on any operating system. libtool makes this transition system dependent as I must compute the correct version-info string for each operating system to have the correct library versions generated out the other end. This is contrary to the desired goals of libtool. I understand the goals of libtools versioning scheme and how it helps people resolve library versioning issues on many systems. In this case, it's preventing me from using the tool as I have a few existing systems that I need to remain compatible with. I propose that libtool take a new command line option '-version-number' which explicitly sets the major/minor/revision number of the output library. This would permit projects to explicitly manage version numbers to remain compatible with pre-libtool releases. -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Migrating existing libraries to libtool
Around 2 o'clock on Feb 18, Simon Richter wrote: To remain binary compatible, it suffices to have the same major version, as programs are expected to link against the .so.major file. Which file this actually symlinks to is irrelevant. So in fact you start off using -version-info major:0:0 and then go on as in the libtool manual. No, that will give minor version 0 which would be seen as *older* than the previous version of the library. I really need major and minor versions to match so I can build replacement versions with the new tools that match precisely with what's already installed. Hrm, how is that solved currently with imake? Imake has all of the necessary system-dependent mechanisms to generate correct link commands given the desired major and minor version numbers. It doesn't modify the version numbers provided, it simply uses whatever pieces are appropriate and ignores the low order values. This has worked for some time now and developers have become comfortable with the kind of version checking and compatibility issues related to the set of platforms this is deployed on. I've tried to use automake for existing X libraries and eventually had to give up and fall back to autoconf as libtool was unable to preserve the correct major and minor versions on even Linux and BSD. I'd rather not be forced to support yet another krufty set of build kludges for X just because libtool has different ideas on library versioning schemes than we've been using for X. automake is so close to working, let's close the gap and let imake die a well deserved death (with apologies to Todd Brunhoff) -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Migrating existing libraries to libtool
Around 23 o'clock on Feb 17, Robert Boehne wrote: Tough problem you've got here, I don't really see a way around it without a new versioning flag other than creating a libX??.la file for the last version of a library you're attempting to install (which may or may not work anyway). Thanks for re-enforcing my understanding of how libtool works. Send in the patch soon, and it could be in the 1.5 release. I'll put something together tomorrow and send it along. -keith ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
