Full_Name: Booker C. Bense Version: Development OS: Solaris 2.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.12.91) - The configure script finds libraries that are shared but not in the default location. In order to build an executable that does not require setting LD_LIBRARY_PATH, you should add -R/path/to/shared_libs to the compile line. Here's an example of the error : Cleaning up in ./test-db... Running slapadd to build slapd database... ld.so.1: ../servers/slapd/tools/slapadd: fatal: libgdbm.so.2: open failed: No such file or directory Killed - If you build slapadd with -R/usr/local/lib (where libgdbm.so.2 is ) it will run.
There is no portable way to ensure that a executable built in one environment will run in another environment. We require the installer to tune their environment such that the built executable will run in most user environments. That is, if the installer has specified to use and locate shared libraries not in the default search path, then the installer is responsible to provide options and flags (such as -R) to configure to ensure built executables can locate detected libraries at run time.
changed state Open to Feedback
On Sat, 4 Dec 1999, Kurt Zeilenga wrote: > There is no portable way to ensure that a executable built in > one environment will run in another environment. We require > the installer to tune their environment such that the built > executable will run in most user environments. > > That is, if the installer has specified to use and locate > shared libraries not in the default search path, then the > installer is responsible to provide options and flags (such > as -R) to configure to ensure built executables can locate > detected libraries at run time. > - But, it is in the default search path. If the configure script adds the -L options it should be smart enough to add the -R options. I didn't give it any special compile options, I just typed configure. If the configure script is going to look in /usr/local without my telling it, it should be prepared to deal with finding a shared library there. - I fully see your position if I had specified something like -L/usr/special/place, it's up to me to add the -R option. -If the configure script is not going to deal with it, I would suggest that you add something to the build documentation to warn people about the issue. - Booker C. Bense
At 06:10 PM 12/4/99 GMT, bbense@networking.stanford.edu wrote: >On Sat, 4 Dec 1999, Kurt Zeilenga wrote: > >> There is no portable way to ensure that a executable built in >> one environment will run in another environment. We require >> the installer to tune their environment such that the built >> executable will run in most user environments. >> >> That is, if the installer has specified to use and locate >> shared libraries not in the default search path, then the >> installer is responsible to provide options and flags (such >> as -R) to configure to ensure built executables can locate >> detected libraries at run time. >> > >- But, it is in the default search path. If the configure script >adds the -L options it should be smart enough to add the >-R options. Our configure script never adds -L options. We do not assume the $CC understands -L or -R or whatever. If it is in the default search path, then the user must have something in her environment to use an alternative search path (or alternative dynamic linker). >I didn't give it any special compile options, I >just typed configure. Something in your environment that specified to use a non-default search path. It could be any number of things to which the configure script is aware of. >If the configure script is going to look in /usr/local without >my telling it, it should be prepared to deal with finding a >shared library there. If /usr/local is not in your systems default search path, then you must have told it to look their or the user is using a complete differnet dynamic linker. The configure script does not modify search paths, it defers this responsibility to the user. >- I fully see your position if I had specified something >like -L/usr/special/place, it's up to me to add the -R option. Exactly. If the user adds a -L without adding a -R, that's his problem. We can not and should not second guess the user. Of course, the compiler/linker selected by the user may have other means for muckying with search paths. The configure script is clueless on how to resolve this issue. It just does what the user tells it to do. >-If the configure script is not going to deal with it, I would >suggest that you add something to the build documentation to >warn people about the issue. Such a warning would best be placed in autoconf documentation as it is not specific to OpenLDAP. WARNING: any program built within a particular environment may not be portable to other environments. ---- Kurt D. Zeilenga <kurt@boolean.net> Net Boolean Incorporated <http://www.boolean.net/>
changed notes changed state Feedback to Closed
executables are not necessarily portable across user environments