On 2006-07-07 14:58, "[EMAIL PROTECTED]@mgedv.net" <[EMAIL PROTECTED]> wrote:
>Giorgos Keramidas wrote:
>>On 2006-07-07 14:22, "[EMAIL PROTECTED]@mgedv.net" <[EMAIL PROTECTED]> wrote:
>>> dunno, if it's a misunderstanding, but my only question "how to tell
>>> the system where to load libraries and in which order to prefer
>>> paths" seems to be still open.
>>> anyway, thx for the reply ;-)
>>> ps: i already RdTFM ;-)
>> You don't.  Unless you modify the /etc/rc.d/ldconfig script manually,
>> /lib and /usr/lib will always be the first to search.
>> I'm still not convinced that "telling the system where to load
>> libraries from" is the solution to you problem, but I don't know what
>> the problem is.  You have to describe first *WHAT* the real problem
>> is and *WHY* you think modifying the library path is a solution.
> i found the ldconfig rc-script but i thought there might be a
> "cleaner" way of telling the system where the shared libraries are to
> be found.
> any way to tell the system: take /usr/local/lib first w.o.  changing
> the ldconfig rc-scripts or developing own startup scripts that achieve
> that?  no way of changing some default configuration file that is
> avail. for that purpose?

No.  For a very good reason too.  If you change the default loader path
to use /usr/local/lib first then *ALL* the programs are affected.  Even
those that are part of the base system.  This is, in general, a very bad
idea as the base-system programs may depend on particular versions of
the libraries to work correctly and those libraries are in /lib:/usr/lib.

> some additional thoughts (a little bit of phil.):
> i wonder, that anybody scripts such hardcoded stuff into a script
> because the environment /etc/ld*conf* exists, and at least for a clear
> and proper way for the admin to define what to load from where it
> should be possible, to override a default configuration via the
> config-files, and not with modifications to rc-scripts which are gone
> by default after each upgrade.

There's a reason why /lib:/usr/lib take precedence over /usr/local.

Don't change that, or be prepared to debug all the potential bugs that
may start appearing.

> to satisfy your couriosity :-)

This description is much better.

> i'd like to compile openssl 0.9.8 and a newer zlib for testing some
> software that does crypto & compression using these libs.  and i
> wanted to keep the servers as clean as possible from changing
> rc-scripts, etc... to ensure we're able to transfer the outcoming
> piece of program to other boxes w'out much effort.  i know it's inside
> the ports but the problem is, we'd like to tes some sort of code
> that's not enabled by default in the ports.

You can always install your own version of openssl and zlib and use an
explicit -R option to tell the linker where to find libraries.  There
are two steps involved in linking and distributing an executable:

    * Build-time linking, where the compiler/linker has to be explicitly
      pointed at teh right place with -L/foo/lib paths.

    * Runtime linking, where the runtime linker-loader has to lookup and
      locate the library.

You can affect the first one with explicit -L/foo/lib options.  You can
also hardcode one or more paths to the binary -- solving the second
problem too -- if you use -R/distrib/lib options while building.

Your problems are only a matter of using the proper build options.

See for example the ldd output near the end of the following log:

# [EMAIL PROTECTED]:/home/giorgos/tmp/foo# make cleandir
# ===> lib (cleandir)
# ===> lib/libz (cleandir)
# rm -f a.out foo.o foo.o.tmp
# rm -f foo.po  foo.po.tmp
# rm -f foo.So foo.so foo.So.tmp
# rm -f libz.so
# rm -f libz.so.* libz.so
# rm -f libz.a libz_p.a libz.so.1
# ===> bin (cleandir)
# ===> bin/foo (cleandir)
# rm -f foo foo.o
# [EMAIL PROTECTED]:/home/giorgos/tmp/foo# make cleandir
# ===> lib (cleandir)
# ===> lib/libz (cleandir)
# rm -f a.out foo.o foo.o.tmp
# rm -f foo.po  foo.po.tmp
# rm -f foo.So foo.so foo.So.tmp
# rm -f libz.so
# rm -f libz.so.* libz.so
# rm -f libz.a libz_p.a libz.so.1
# ===> bin (cleandir)
# ===> bin/foo (cleandir)
# rm -f foo foo.o
# [EMAIL PROTECTED]:/home/giorgos/tmp/foo# make obj
# ===> lib (obj)
# ===> lib/libz (obj)
# /home/giorgos/tmp/foo/obj/home/giorgos/tmp/foo/lib/libz created for 
# ===> bin (obj)
# ===> bin/foo (obj)
# /home/giorgos/tmp/foo/obj/home/giorgos/tmp/foo/bin/foo created for 
# [EMAIL PROTECTED]:/home/giorgos/tmp/foo# make
# ===> lib (all)
# ===> lib/libz (all)
# cc -O2 -fno-strict-aliasing -pipe -I/home/giorgos/tmp/foo/lib/libz -g 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c 
# building static z library
# ranlib libz.a
# cc -pg -O2 -fno-strict-aliasing -pipe -I/home/giorgos/tmp/foo/lib/libz -g 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c 
/home/giorgos/tmp/foo/lib/libz/foo.c -o foo.po
# building profiled z library
# ranlib libz_p.a
# cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe 
-I/home/giorgos/tmp/foo/lib/libz -g -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -c /home/giorgos/tmp/foo/lib/libz/foo.c -o 
# building shared library libz.so.1
# ===> bin (all)
# ===> bin/foo (all)
# cc -O2 -fno-strict-aliasing -pipe 
-I/home/giorgos/tmp/foo/bin/foo/../../lib/libz -g  -c 
# cc -O2 -fno-strict-aliasing -pipe 
-I/home/giorgos/tmp/foo/bin/foo/../../lib/libz -g   -L- 
-L/usr/lib -R/tmp/lib -o foo foo.o -lz
# [EMAIL PROTECTED]:/home/giorgos/tmp/foo# make install
# ===> lib (install)
# ===> lib/libz (install)
# install -C -o root -g wheel -m 444   libz.a /tmp/lib
# install -C -o root -g wheel -m 444   libz_p.a /tmp/lib
# install  -o root -g wheel -m 444     libz.so.1 /tmp/lib
# ln -fs libz.so.1 /tmp/lib/libz.so
# ===> bin (install)
# ===> bin/foo (install)
# install  -o root -g wheel -m 555   foo /tmp/bin
# [EMAIL PROTECTED]:/home/giorgos/tmp/foo# ldd /tmp/bin/foo
# /tmp/bin/foo:
#         libz.so.1 => /tmp/lib/libz.so.1 (0x2807c000)
#         libc.so.7 => /lib/libc.so.7 (0x2807e000)
# [EMAIL PROTECTED]:/home/giorgos/tmp/foo#

Note how the /tmp/bin/foo executable depends on `libz' but it knows
where to pick it up from.  No conflict with the system version of
libz.so and certainly no problems when the utility runs:

# [EMAIL PROTECTED]:/home/giorgos/tmp/foo# /tmp/bin/foo
# 1
# 0
# 1
# 0
# 1
# 0
# 1
# 0
# 1
# 0
# [EMAIL PROTECTED]:/home/giorgos/tmp/foo#

The Makefile of this `foo' program and the library it uses can be found
online at:


What you can do to override on a _per_program_ basis the location of
libraries is to use:

    * Proper -L/build/path/lib options when compiling to let the
      compiler file the build-time version of the library.

    * Proper -R/runtime/path/lib options when compiling to add hints
      about the location of the libraries in the binary.  This way, the
      runtime linker will know where to look for shared libs.

> my (very subjective) point of view currently is, that the dynamic
> loading environment could rely on just one (or 2 if you care for
> elf/aout anymore) configuration file, which is being taken care of the
> libexec-stuff.

It does.  These paths are /lib and /usr/lib, and there is no good reason
to change them to satisfy just one program.

> and assume the following:
> you're compiling ~10 libraries in series (all go to /usr/local) and
> they're some sort of connected to each other, you'll always have to
> exec ldconfig -blabla... to ensure, the loader knows about the new
> lib?

Nope.  The libraries should include -R options that point to the right
place for their dependencies.

It's the responsibility of the builder & packager to make sure these
thigns are done Right(TM), so you won't have to fiddle with tons of
conflicting options and LD_LIBRARY_PATH trickery to have something that
sort of works.

Just think about it...

    [case 1]

    Let's say that today you install something that requires
    /usr/local/lib to be the first, just because the guy who
    compiled libfoo.so thought this was a good idea.

    Then you have to install something else, which depends on
    /usr/lib being first because another developer thought this
    was a good idea too (or simpe because his program has been
    built with the system version of the same library).

    Suddenly, you can only have *one* of these working.

    [case 2]

    You install FreeBSD, which comes with a few dozen tools that
    use Gzip compression.  FreeBSD comes bundled with a carefully
    tuned, debugged, tested and QA'd version of libz.so -- a
    library which works 100% as expected with the system

    Then one day, you install software package Frobnic Express,
    from a company who thought it is a marvelous idea to depend
    on /usr/local being the first library lookup path.  You
    switch, and suddenly nothing from the base system works
    correctly.  Programs crash, create bogus output files, or
    randomly misbehave.  After a week of effort, you find that
    this is because Frobnic Express installed an incompatible
    libz.so in /usr/local/lib which the system binaries can never
    work well with.

It's just not a good idea.  Avoid it.  At all costs.  The hell of
maintenance effort you will have to go through when things go wrong is
not nice.  Trust me when I say you won't like it at all :-)

> hey, i'm not a real developer (as you can see) and i really
> am sure that there was a reason for developing that way.
> i'm also sure, that you can explain good reasons for doing
> it that way (and i wouldn't ever say "i don't care 'bout that!")
> but from a more or less "user's" point of view, it's admin-
> overhead which could (theoretically) be avoided.
> i'll STFU know - things are going too theoretically ;-)

This may sound a bit harsh, but if you are not a developer, why are you
compiling things?

On the other hand, look at the sample `foo-rtld.tgz' tarball I created.
See how the fake `libz' and the `foo' utility that depend on it work.
See how they are compiled, and try to use a similar scheme :)

I hope this clarifies a bit why I think you are headed down a very wrong
path by trying to override /lib and /usr/lib's precedence...


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to