Re: Alternate SONAME values

2005-07-08 Thread Ganesan Rajagopal
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

2005-07-08 Thread Ganesan Rajagopal
>>>>> "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

Re: Alternate SONAME values

2005-07-08 Thread Ganesan Rajagopal
>>>>> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes: > On Fri, 2005-07-08 at 09:24 +0530, Ganesan Rajagopal wrote: >> But libXaw.so. is the default behaviour for libtool. Are you >> using -release instead of -version-info or -version-number? I

Re: Alternate SONAME values

2005-07-07 Thread Ganesan Rajagopal
>>>>> "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 ano

Re: Alternate SONAME values

2005-07-07 Thread Ganesan Rajagopal
>>>>> "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 ano

Re: Alternate SONAME values

2005-07-07 Thread Ganesan Rajagopal
bXaw7.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 -- Gane

Re: Using -Bsymbolic with libtool

2001-05-09 Thread Ganesan Rajagopal
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: > I think you can get the exact same result by using the > -Wl,-Bsymbolic flag. It will be recognized by Libtool, > and passed to the linker. -Xlinker is a gcc equivalent > to -Wl, so if I recall correctly, that would only work > when

Using -Bsymbolic with libtool

2001-05-08 Thread Ganesan Rajagopal
Hi, I am currently using -Bsymbolic to compile my libraries. I pass in the flag using "-Xlinker -Bsymbolic". Is "-Bsymbolic" portable and if it is can the flag be added to libtool directly. Linux, FreeBSD ELF, Tru64 and Solaris seem to support it (with the same flag), but I am sure there will be

Re: interdependancies between libraries

2001-01-17 Thread Ganesan Rajagopal
> "Brian" == Brian May <[EMAIL PROTECTED]> writes: > "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes: >>> On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: > >>> Oh, another observation: installing the libraries in their >>> non-final > location (as required for Debian packaging

PATCH: Support for export-symbols for osf[345]* C libraries

2000-10-10 Thread Ganesan Rajagopal
Hi, The attached patch adds support for exporting symbols on OSF platforms. I have only tested on Compaq Tru64 4.0. If this patch is okay, I'll submit a similar patch for ltcf-cxx.sh. The patch is against the top of multi-language-branch. Ganesan =

Re: $ORIGIN in RPATHs

2000-10-10 Thread Ganesan Rajagopal
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Oct 10, 2000, Ganesan Rajagopal <[EMAIL PROTECTED]> wrote: > > > While we are on this topic, how about modifying libtool to add a > > $ORIGIN in a program RPATH instead of an hardcoded path if > > possible? Thi

$ORIGIN in RPATHs

2000-10-09 Thread Ganesan Rajagopal
I would like to add an RPATH with $ORIGIN (supported on Solaris and GLIBC platforms), but libtool complains that an absolute path is needed. A following trivial fix to ltmain.in fixes the problem. The patch is against the top of the multi-language-branch. ltmain.in patch start -