[Mono-dev] Library path bug in Makefile?

[Edward Ned Harvey (mono)]

> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
> bounces at lists.ximian.com] On Behalf Of "Andrés G. Aragoneses"
> 
> As far as I understand, LD_LIBRARY_PATH is a system setting that mono
> doesn't modify.

Thanks for your response - from the link I originally posted (http://www.cc.dtu.dk/?page_id=304) please see this quote:

> There is the ldd command, that shows you which libraries are needed 
> by a dynamically linked executable, e.g.
> 
> $ ldd /usr/bin/file
>         linux-vdso.so.1 =>  (0x00007fff9646c000)
>         libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00000030f9a00000)
>         libz.so.1 => /lib64/libz.so.1 (0x00000030f8e00000)
>         libc.so.6 => /lib64/libc.so.6 (0x00000030f8200000)
>         /lib64/ld-linux-x86-64.so.2 (0x00000030f7a00000)
> 
> <snip>
> 
> If you compile your application(s) yourself, you can solve the problem by 
> specifying the correct location of the shared libraries and tell the linker to 
> add those to the runpath of your executable, specifying the path in the 
> '-rpath' linker option:
> cc -o myprog obj1.o ... objn.o -Wl,-rpath=/path/to/lib \
>    -L/path/to/lib -lmylib
>
> The linker also reads the LD_RUN_PATH environment variable,

The main point here is to say, the library search path is hard-coded into the binary at the time of compile/linking.

In fact, you're correct.  LD_LIBRARY_PATH is an environment variable, and in fact, mono doesn't modify it.  (Rightly so.)  Normally, LD_LIBRARY_PATH is actually empty.  Completely blank.  And rightly so.  Because normally it should not be needed, if the binaries are linked properly.

In the case of building mono from source, it seems clear, this should come from --libdir=DIR, which is derived from --exec-prefix=EPREFIX, which is derived from --prefix=PREFIX

The goal I'm driving toward is to provide a modern version of mono on systems (for example centos) which don't have anything remotely usable available in their standard package repositories.  (In the default centos/rhel repositories, there is *no* mono available, but if you add epel, then suddenly mono 2.4.3 becomes available, which is pathetic.)  It's very easy to build from source, but without a package manager, you DON'T want to install into default locations, as that makes it very difficult and messy to upgrade to later versions of mono as they're released, with security and bugfixes.  The methodology I've described in the original post about building to /usr/local/mono-VERSION and then providing a symlink /usr/local/mono --> mono-VERSION   is very easily supportable and sustainable.  You can build and install the new 3.2.9 when it's available, test it yourself, and then cutover the symlink when it's ready for general usage by the users of the machine.


> http://www.mono-project.com/Parallel_Mono_Environments

Thank you for the link.  In fact, I read it.  Fundamentally, they're suggesting you override the LD_LIBRARY_PATH (and some other environment variables.)  

It also seems, they are in agreement with all the other info about LD_LIBRARY_PATH conventions out there on the internet, they are *not* suggesting that you do this in production.  They are operating under the assumption that you are building multiple versions of mono for development and testing purposes.  They assume you have some other mono in system default locations, and you don't want the system default mono to interfere with your experimental build (or vice-versa).