W <none@anyisp.com> wrote:

> This is one part of Solaris I have never been able to come to grips with
> - I guess I have been using Linux too long with /etc/ld.so.conf

Is there any significant difference between the two? Both do runtime
loading. Both have a system-wide configuration (/etc/ld.so.conf
vs. /var/ld/ld.config).

It's just that system-wide overrides (whether through an over-agressive
LD_LIBRARY_PATH or through ld.config) can cause problems, so getting it
right at compile/link time (via -R) or with run-time wrappers (a limited
LD_LIBRARY_PATH) is preferred by many.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

On Mon, 07 Mar 2005 23:37:08 +0000, Darren Dunham wrote:

> W <none@anyisp.com> wrote:
>
>> This is one part of Solaris I have never been able to come to grips with
>> - I guess I have been using Linux too long with /etc/ld.so.conf
>
> Is there any significant difference between the two? Both do runtime
> loading. Both have a system-wide configuration (/etc/ld.so.conf
> vs. /var/ld/ld.config).

The difference is that Linux distributors and developers fail to use the
-R or -rpath arguments and thus *rely* on a crle type of environment.
These people have no concept of what ELF is about. There is no need
whatsoever for either of those files in a properly built system, whether
Linux or Solaris.

[Dave Uhring]:
>
> The difference is that Linux distributors and developers fail to
> use the -R or -rpath arguments and thus *rely* on a crle type of
> environment. These people have no concept of what ELF is about.
> There is no need whatsoever for either of those files in a
> properly built system, whether Linux or Solaris.

although it may be historically true, I don't think it is true today.
what software do you have in mind? these days it seems to me most
applications use libtool for building, and although clunky, it does
get -rpath right

Linux' ld.so doesn't support $ORIGIN, though. its concept of "safe"
directory is also hardcoded to /lib and /usr/lib, and can't be
configured as in Solaris.
--
Kjetil T.

On Tue, 08 Mar 2005 01:59:03 +0100, Kjetil Torgrim Homme wrote:

> [Dave Uhring]:
>>
>> The difference is that Linux distributors and developers fail to
>> use the -R or -rpath arguments and thus *rely* on a crle type of
>> environment. These people have no concept of what ELF is about.
>> There is no need whatsoever for either of those files in a
>> properly built system, whether Linux or Solaris.
>
> although it may be historically true, I don't think it is true today.
> what software do you have in mind? these days it seems to me most
> applications use libtool for building, and although clunky, it does
> get -rpath right

Just one example in Slackware-10.0 should suffice. I removed
/etc/ld.so.cache and

# ldd /usr/bin/gtv
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40016000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40134000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40165000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40168000)
libdl.so.2 => /lib/libdl.so.2 (0x4018a000)
libXext.so.6 => not found
libX11.so.6 => not found
[ ... ]

What happens with *your* Linux distro if you remove /etc/ld.so.cache?

Dave Uhring wrote:

> On Tue, 08 Mar 2005 01:59:03 +0100, Kjetil Torgrim Homme wrote:
>
>
>>[Dave Uhring]:
>>
>>> The difference is that Linux distributors and developers fail to
>>> use the -R or -rpath arguments and thus *rely* on a crle type of
>>> environment. These people have no concept of what ELF is about.
>>> There is no need whatsoever for either of those files in a
>>> properly built system, whether Linux or Solaris.
>>
>>although it may be historically true, I don't think it is true today.
>>what software do you have in mind?

> Just one example in Slackware-10.0 should suffice. I removed
> /etc/ld.so.cache and

> # ldd /usr/bin/gtv
> libXext.so.6 => not found
> libX11.so.6 => not found

> What happens with *your* Linux distro if you remove /etc/ld.so.cache?

Umm, it puts me in the mood to remove the rest of the Linux distribution
as well? :-)

- Logan

On Tue, 08 Mar 2005 01:47:31 +0000, Logan Shaw wrote:

> Umm, it puts me in the mood to remove the rest of the Linux distribution
> as well? :-)

Well, for a desktop OS Linux is not all that bad. It just has a few
problems:

o Absolute lack of backward compatibility, guaranteed by Torvalds.
o Inability to consistently probe the PCI bus. On reboot what was eth0
becomes eth1 and vice versa. Makes remote administration a lot of fun.
Note that this problem can be "corrected" with a userland utility.
o Designed, maintained and distributed by a bunch of diletantes who would
rather use some crutch like /etc/ld.so.conf rather than the correct
linking arguments. Solaris crle is not one bit better in that regard.

Note that the handy part of the Solaris crle implementation
is that one can use the -c option to the linker to specify
an application-specific configuration file... and this file
can be kept relative to the application's path using the
$ORIGIN keyword. As a result, you can specify the application's
dependancy's locations at install time w/o relinking anything
by generating a ld.config file in the correct location.

- Bart

barts@smaalders.net wrote:
> Note that the handy part of the Solaris crle implementation
> is that one can use the -c option to the linker to specify
> an application-specific configuration file... and this file
> can be kept relative to the application's path using the
> $ORIGIN keyword. As a result, you can specify the application's
> dependancy's locations at install time w/o relinking anything
> by generating a ld.config file in the correct location.

This sounds like a neat idea. But there's one problem: it only
works on Solaris. So, that's OK for binary packages, but it is
just not likely to make it into the Makefiles of open source
software. Likewise with $ORIGIN. Nobody wants to make an install
script that works differently on one platform than on all others.

So, I think Sun could actually make Solaris administration easier
if they spent some effort on getting $ORIGIN put into other Unix
and Unix-like operating systems, especially Linux. If they could
get $ORIGIN to become a more standard Unix thing, real world
software would take advantage of it, and then its benefits would
be more than academic.

- Logan

Gnu ld already has added support for this
with the -z origin flag.

http://www.die.net/doc/linux/man/man1/ld.1.html

Now the trick is to ween people from doing it wrong - but
that's harder; we still don't have people completely trained
on Solaris.

- Bart

Dave Uhring wrote:

> The difference is that Linux distributors and developers fail to use the
> -R or -rpath arguments and thus *rely* on a crle type of environment.
> These people have no concept of what ELF is about.

I do not think this is the case. ELF defined RPATH as having higher
priority than LD_LIBRARY_PATH. Sun violated the spec in Solaris 2.0, but
(some?) other systems did not. On the system where RPATH has higher
priority you cannot correct stupidly built software by writing a shell
script. You cannot do many other things, as well.

That's why ELF's RPATH is being avoided on those systems, I think.

Ten or so years later everybody agreed that the original ELF specification
was stupid. So ELF got RUNPATH which does what RPATH has always been doing
on Solaris and RPATH is deprecated. I would expect that RUNPATH is mostly
implemented in various linkers by now. The problem now is that developers
are used to doing things in a certain way.

--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| dave@fly.srk.fer.hr