Re: Using libtool together with the ${ORIGIN} soname variable

[r ve]

Hi,

> There is nothing to say against installing these libraries into
> $(libdir), although you can also simply link them statically when they
> are used by only one program (gives you a 5% speed bonus on i386, as
> shared libraries need one register to point to itself, as they may be
> mapped to different virtual addresses in different process spaces).

Nope, these libraries aren't only used by the main executable so the code 
has to stay in the shared libs.
(also because the program + libs is quite large, linking statically would 
result in way too much duplicated code)


> Erm, installation program? Don't do that, most admins won't use it
> anyway, since they cannot control where stuff is installed other than by
> putting it inside a chroot jail. Believe me, people are glad if you help
> them by making this a no-surprises installation rather than an
> easy-for-most-users installation. Who cannot install software that comes
> in regular packages usually uses prepackaged software in .deb or .rpm
> format or instructs their sysadmin to install the sw.

We're not talking about a program for geeky users and other type of users 
who like or have to fiddle with their systems all day long.
This program isn't meant for those people (including admins).

It is meant for Joe Average, that's why there's going to be an 
easy-for-most-users install.
(and an additional tarball for those who like to use that instead)


> Even then, paths in sonames are not portable and (in most cases) are
> stripped anyway by the linker.

Atually, there is _no_ path at all in the soname when using this ${ORIGIN} 
variable.
It's replaced by the library loader when using ldd or executing the program 
that needs the lib.


However, this all doesn't give me an answer for my question ;)

Thanks,
Richard

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail