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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
15 matches
Mail list logo
