RE: shared library loader configuration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giorgos Keramidas Sent: Friday, July 07, 2006 3:46 PM To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Subject: Re: shared library loader configuration 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 # rm -f .depend GPATH GRTAGS GSYMS GTAGS # === bin (cleandir) # === bin/foo (cleandir) # rm -f foo foo.o # rm -f .depend GPATH GRTAGS GSYMS GTAGS # [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 # rm -f .depend GPATH GRTAGS GSYMS GTAGS # === bin (cleandir) # === bin/foo (cleandir) # rm -f foo foo.o # rm -f .depend GPATH GRTAGS GSYMS GTAGS # [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 /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 # [EMAIL
Re: shared library loader configuration
On 2006-07-10 15:07, [EMAIL PROTECTED]@mgedv.net [EMAIL PROTECTED] wrote: Giorgos Keramidas wrote: [lengthy example about compiling with -L and -R options] 1st of all, thx for the efforts to clarify things. No problem :) but now, i use -L and -R, this works fine (until now) and maybe it's not necessary anymore, to workaround ldconfig. Thanks for taking the time to post a followup that it all works now. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
shared library loader configuration
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 ;-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shared library loader configuration
On 2006-07-07 13:22, [EMAIL PROTECTED]@mgedv.net [EMAIL PROTECTED] wrote: 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. In short, just don't. The system programs have been tested, developed and debugged with the *SYSTEM* version of the libraries. Blindly replacing these libraries with others is something you should do only with extreme care. what has to be set/changed, to have this setting as soon as the OS starts? LD_LIBRARY_PATH is probably what you mean here. 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. All the compilers that I have to use for every day work and for my own stuff have options that can hardcode a 'runtime library path' in the ELF binary. What did you try to compile? What do you mean by writing ``the compilation does not even find the new libraries''? please don't tell me things about RTFM or weblinks This is also a good way of learning new stuff though :) i just need ~3 simple lines of what the hell to do that i get a persisting setting for compilations and runtimes How do you know it is ``3 simple lines''? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: shared library loader configuration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giorgos Keramidas Sent: Friday, July 07, 2006 2:03 PM To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Subject: Re: shared library loader configuration On 2006-07-07 13:22, [EMAIL PROTECTED]@mgedv.net [EMAIL PROTECTED] wrote: 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. In short, just don't. The system programs have been tested, developed and debugged with the *SYSTEM* version of the libraries. Blindly replacing these libraries with others is something you should do only with extreme care. what has to be set/changed, to have this setting as soon as the OS starts? LD_LIBRARY_PATH is probably what you mean here. 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. All the compilers that I have to use for every day work and for my own stuff have options that can hardcode a 'runtime library path' in the ELF binary. What did you try to compile? What do you mean by writing ``the compilation does not even find the new libraries''? please don't tell me things about RTFM or weblinks This is also a good way of learning new stuff though :) i just need ~3 simple lines of what the hell to do that i get a persisting setting for compilations and runtimes How do you know it is ``3 simple lines''? 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 ;-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shared library loader configuration
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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: shared library loader configuration
-Original Message- From: Giorgos Keramidas [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 2:28 PM To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Subject: Re: shared library loader configuration 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? 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 ;-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shared library loader configuration
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 # rm -f .depend GPATH GRTAGS GSYMS GTAGS # === bin (cleandir) # === bin/foo (cleandir) # rm -f foo foo.o # rm -f .depend GPATH GRTAGS GSYMS GTAGS # [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 # rm -f .depend GPATH GRTAGS GSYMS GTAGS # === bin (cleandir) # === bin/foo (cleandir) # rm -f foo foo.o # rm -f .depend GPATH GRTAGS GSYMS GTAGS # [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 /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 # [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 /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
