[Mono-dev] Library path bug in Makefile?

["Andrés G. Aragoneses"]

On 04/03/14 17:23, Edward Ned Harvey (mono) wrote:
>> 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.

Right, LD_LIBRARY_PATH may be simply a fallback. But the thing is, you
don't need LD_LIBRARY_PATH when installing libs in standard prefixes
like /usr or /usr/local, so as you mention that LD_LIBRARY_PATH is
empty, maybe what happens is that PATH is checked before
LD_LIBRARY_PATH? (In that case, LD_LIBRARY_PATH is the fallback of the
fallback.)


> 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. 

But even if you symlink /usr/local/mono to /usr/local/mono-3.2.8, that
is *not* /usr/local. I mean, its lib folder would be in
/usr/local/mono/lib instead of /usr/local/lib, which means that if
/usr/local is considered standard for your distro (included in PATH?),
that would not apply in this case.

If mono is simply the only software you install from sources, you can
simply install it in /usr/local, and when you need to uninstall it, you
simply wipe /usr/local.

If you're worried about mixing different mono versions around the same
prefix, then what you could do is dummy packages using fpm (an example
of how to create a .deb package is here:
https://github.com/knocte/7digital-mono, but you can create an rpm as
easily as that, changing a flag). Then uninstalling becomes easy.


> 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).

Yes I know that guide is not meant to help you with your production
environment, but by reading it you understand that using non-standard
prefixes (like /opt/mono or /usr/local/mono-3.2.9) only really works if
you use them along with an isolated environment (a script you 'source'
into, etc).