[Gambas-user] Problem with directory /lib

[Benoît Minisini]

> -----Mensaje original-----
> De: craf <prog at ...2177...>
> Reply-to: mailing list for gambas users
> <gambas-user at lists.sourceforge.net>
> Para: Lista Gambas Ingles <gambas-user at lists.sourceforge.net>
> Asunto: [Gambas-user] Problem with directory /lib
> Fecha: Mon, 19 Apr 2010 11:15:32 -0400
> 
> >Hi.
> >
> >I managed to install a console program compiled on Ubuntu 9.04 to Ubuntu
> >8.04, using shared libraries.
> >The problem is with a program that uses the GTK or QT library, and they
> >require the libraries that are in the lib folder, and take into account
> >that come with the PC and not those that are packaged with the project.
> >Example. If I provide shared libraries are located in the lib folder,
> >should be exported with the following:
> >
> >export LD_LIBRARY_PATH
> >=/opt/proyect/gambas2/lib_shared/lib:/opt/proyect/gambas2/lib_shared/usr/l
> >ib
> >
> >The path /usr/lib is taken into account, but the path /lib, and take the
> >PC where you are installing the program.
> >
> >I also tested:
> >
> >export LD_LIBRARY_PATH =
> >$LD_LIBRARY_PATH:/opt/proyect/gambas2/lib_shared/lib:/opt/proyect/gambas2/
> >lib_shared/usr/lib
> >
> >export LD_LIBRARY_PATH
> >=/opt/proyect/gambas2/lib_shared/lib:/opt/proyect/gambas2/lib_shared/usr/l
> >ib:$LD_LIBRARY_PATH
> >
> >but nothing...
> >
> >Is there any way to force you to take the path /lib specified in the
> >file .sh by one and not the PC?
> >
> >Regards
> >--------------------------------------------------------------------------
> >---- Download Intel® Parallel Studio Eval
> >Try the new software tools for yourself. Speed compiling, find bugs
> >proactively, and fine-tune applications for parallel performance.
> >See why Intel Parallel Studio got high marks during beta.
> >http://p.sf.net/sfu/intel-sw-dev
> >_______________________________________________
> >Gambas-user mailing list
> >Gambas-user at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/gambas-user
> 
> Hi.
> 
> Searching the Internet the reason why the put the path to the
> folder /lib in the LD_LIBRARY_PATH variable is not taken into account,
> if you take into account the /lib of the computer where the program is
> being installed with shared libraries.
> 
> He added explanation found:
> 
> ----------------------------------------------------------------------
> "It is very possible to have multiple versions of glibc on the same
> system (we do that every day).
> 
> However, you need to know that glibc consists of many pieces (200+
> shared libraries) which all must match. One of the pieces is
> ld-linux.so.2, and it must match libc.so.6, or you'll see the errors you
> are seeing.
> 
> The absolute path to ld-linux.so.2 is hard-coded into the executable at
> link time, and can not be easily changed after the link is done.<---THAT
> IS THE PROBLEM¡¡¡
> 
> To build an executable that will work with the new glibc, do this:
> 
> g++ main.o -o myapp ... \
>    -Wl,-rpath=/path/to/newglibc \
>    -Wl,-dynamic-linker=/path/to/newglibc/ld-linux.so.2
> 
> The -rpath linker option will make the runtime loader search for
> libraries in /path/to/newglibc (so you wouldn't have to set
> LD_LIBRARY_PATH before running it), and the -dynamic-linker option will
> "bake" path to correct ld-linux.so.2 into the application."
> 
> source:http://stackoverflow.com/questions/847179/multiple-glibc-libraries-o
> n-a-single-host/851229#851229
> --------------------------------------------------------------------------
> --------------
> 
> In short, if I want to be transported for example ld-linux.so.2 file
> from a computer with Ubuntu 9.10 to another distribution that does not
> have the same version. I can only do so if at compile Gambas added
> routes where I have copied my shared libraries, so that then can be
> called with the variable LD_LIBRARY_PATH.
> 
> Now, I saw also that you can use the LD_PRELOAD variable, Can I use?.
> 
> Regards.
> 

So I suggest that you always use the glibc stuff of the target system 
(libc.so, ld-linux.so, libffi.so...), and provide the other shared libraries 
only. 

Apparently only the ld-linux.so path is hardcoded (at least on my Mandriva), 
and points at /lib. I think this should be the path used by all distributions, 
so that should not be the problem. All other shared libraries used by the 
interpreter are resolved at runtime.

$ ldd gbx3
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/i686/libm.so.6 (0xb786e000)
        libintl.so.8 => /lib/libintl.so.8 (0xb7863000)
        libc.so.6 => /lib/i686/libc.so.6 (0xb7702000)
        libdl.so.2 => /lib/libdl.so.2 (0xb76fd000)
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb76e2000)
        libffi.so.5 => /usr/lib/libffi.so.5 (0xb76db000)
        /lib/ld-linux.so.2 (0xb78b5000)

Regards,

-- 
Benoît Minisini