@nospam: "hi,
can someone give me please a SIMPLE and CLEAR answer,
what i exactly have to do to achieve the following:
i have (for example) installed a new compiled version
of libz.a/.so in /usr/local.
i want program (during runtime AND during compilation)
to compile and run against the NEW and non-system libs.
what has to be set/changed, to have this setting as soon
as the OS starts?
i tried running ldconfig, i was playing around with some
ld-so.conf files, everything failed. the compilation does
not even find the new libraries, and if i use "ldd" to
check what path the lib would use it's always /lib or
/usr/lib instead of /usr/local/lib.
please don't tell me things about RTFM or weblinks, i just
need ~3 simple lines of what the hell to do that i get
a persisting setting for compilations and runtimes, which
i don't have to e.g. export everytime i want it to work
(talking 'bout LD_LIBRARY_PATH or CFLAGS/LDFLAGS). this
cannot be a good solution, as soon as i start with a clean
environment, there has to be a way to tell the os, MAN load
it from there first!
many thx in advance for not flaming me & telling me how's
it meant to be ;-)
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
    @nospam: "<quote>
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?
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.
to satisfy your couriosity :-)
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.
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.
i exactly don't see the need for caching all "found" libs
inside another config in var (even this can speed up things
a little bit), a need for the ldconfig command (which renders
things to do twice and which - maybe i don't get it (plz. no
flame-wars ;-) ) - doesn't really take care for the config-
files from /etc as well.
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?
it's like the crazieness of the windows registry: i need 10ths
of entries for one library to really make it avail in the os
and for progs relying on it.
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 ;-)
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
    @keramida: "<quote>
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.
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.
This description is much better.
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:
# root@gothmog:/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
# rm -f .depend GPATH GRTAGS GSYMS GTAGS
# ===> bin (cleandir)
# ===> bin/foo (cleandir)
# rm -f foo foo.o
# rm -f .depend GPATH GRTAGS GSYMS GTAGS
# root@gothmog:/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
# rm -f .depend GPATH GRTAGS GSYMS GTAGS
# ===> bin (cleandir)
# ===> bin/foo (cleandir)
# rm -f foo foo.o
# rm -f .depend GPATH GRTAGS GSYMS GTAGS
# root@gothmog:/home/giorgos/tmp/foo# make obj
# ===> lib (obj)
# ===> lib/libz (obj)
# /home/giorgos/tmp/foo/obj/home/giorgos/tmp/foo/lib/libz created for /home/giorgos/tmp/foo/lib/libz
# ===> bin (obj)
# ===> bin/foo (obj)
# /home/giorgos/tmp/foo/obj/home/giorgos/tmp/foo/bin/foo created for /home/giorgos/tmp/foo/bin/foo
# root@gothmog:/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 /home/giorgos/tmp/foo/lib/libz/foo.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 foo.So
# 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 /home/giorgos/tmp/foo/bin/foo/foo.c
# cc -O2 -fno-strict-aliasing -pipe -I/home/giorgos/tmp/foo/bin/foo/../../lib/libz -g   -L- -L/home/giorgos/tmp/foo/bin/foo/../../lib/libz -L/home/giorgos/tmp/foo/obj/home/giorgos/tmp/foo/bin/foo/../../lib/libz -L/usr/lib -R/tmp/lib -o foo foo.o -lz
# root@gothmog:/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
# root@gothmog:/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)
# root@gothmog:/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:
# root@gothmog:/home/giorgos/tmp/foo# /tmp/bin/foo
# 1
# 0
# 1
# 0
# 1
# 0
# 1
# 0
# 1
# 0
# root@gothmog:/home/giorgos/tmp/foo#
The Makefile of this `foo' program and the library it uses can be found
online at:
<url>
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.
It does.  These paths are /lib and /usr/lib, and there is no good reason
to change them to satisfy just one program.
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
    binaries.
    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 :-)
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...
Regards,
Giorgos
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
    @nospam: "<quote>
1st of all, thx for the efforts to clarify things. not
everybody would take this amount of time for a lazy bugger
like me who doesn't like to change env-vars and compiler-
args.
as mentioned, i preferred a simple "switch" that renders the 
whole compile thing as a "change it, forget about it" thing.
that this will break up thinks, is obvious. and i already
thought about it (additionally, i thought it might be good
for the os to e.g. use openssl-0.9.8b instead of 0.9.7e,
where many improvements (security and speed) have been made.
but as far as i could figure out, most things are linked
against the specific version and changing ld-paths doesn't
affect anything.
ok dude, you convinced me a little bit and if it were more
effort than changing centralized scripts written by us, i'd
still wanted to change ldconfig ;-)
but now, i use -L and -R, this works fine (until now) and
maybe it's not necessary anymore, to workaround ldconfig.
regards ;-)
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
    @keramida: "<quote>
No problem :)
Thanks for taking the time to post a followup that it all works now.
_______________________________________________
<email_address> mailing list
<url>
To unsubscribe, send any mail to "<email_address>""
{'source': 'USENET', 'other_information': '{"reply_count": 4, "forum_name": "list.freebsd.questions.20141017.mbox"}', 'file': 'data/output/usenet-list.freebsd.parquet'}