Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • This is one of the most common issues I run into when installing software where the libraries are someplace other than /usr/lib (often happens with x64 based platforms which use /usr/lib64). The best solution I've found (at least on distros that support it) is to add the library path to /etc/

    Any suggestions on what to do besides LD_LIBRARY_PATH when you need to link against a library in an oddball place like /opt/custom/magicfoo/lib or something similar? I'm all ears :)

    • The best solution I've found (at least on distros that support it) is to add the library path to /etc/

      I've just discovered the document I linked to is not the same as the original. If you can hunt down the original (try Internet archive, I can't as I'm at work and it's blocked :P ), it's a must read, and it talks about and why it's a bad idea. In short, what about when you need something linked against one specially compiled version of in /usr/local/junk and something else linked against a differently compiled version of in /opt/apps/junk?

      Theoretically, when you run the linker, you can use a -R option or the LD_RUN_PATH environment variable to hardwire the proper location for libraries into the executable. In practice, what you really need is something to pass to configure or Makefile.PL or what have you -- and it's just not there! The people who set up these config scripts don't understand the need. It's a mess. (Also, when you get a lot of library-related options on the gcc or linker line, it seems to get really confused. I'm sure that the truth is that I get really confused and the linker does just what it's supposed to do -- but it's very order-dependent in a strange way, and I don't understand it, yet.)

      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers