Re: Alternate SONAME values

[Keith Packard]

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