[Gambas-user] Problem with PATH to shared library - part 2

[Doriano Blengino]

craf ha scritto:
>
>>
>> I forgot in the previous mail indicate the steps I have done:
>>
>> First run the command $ ldd gbr2 to see if there were dependency
>> problems, which I produced the following result:
>>
>> $ Ldd gbr2
>> linux-gate.so.1 => (0xb770d000)
>> libm.so.6 => / lib/tls/i686/cmov/libm.so.6 (0xb76db000)
>> libdl.so.2 => / lib/tls/i686/cmov/libdl.so.2 (0xb76d7000)
>> libpthread.so.0 => / lib/tls/i686/cmov/libpthread.so.0 (0xb76be000)
>> libffi.so.5 => not found
>> libc.so.6 => / lib/tls/i686/cmov/libc.so.6 (0xb756f000)
>> / Lib/ld-linux.so.2 (0xb770e000)
>>
>> This tells me they can not find the shared library libffi.so.5, for
>> which issued the command:
>> $ Tree opt
>>
>>  my_project/
>>
>> |-- gambas2
>> |
>> |   |-- bin
>> |   |
>> |   |   |-- gbr2
>> |   |   
>> |   |   `-- gbx2
>> |   |
>> |   |-- lib
>> |   |
>> |   |   `-- gambas2
>> |   |   
>> |   |       |-- blah blah blah...
>> |   
>> |   `-- library_shared
>> |   
>> |       |-- lib
>> |       |
>> |       |   |-- blah blah blah...
>> |       
>> |       `-- usr
>> |       
>> |           `-- lib
>> |           
>> |               |-- blah blah blah...
>> |               |-- libexpat.so.1
>> |               |-- libexpat.so.1.5.2
>> |               |-- libffi.so.5- - - - - - - - - - - - - > ¡THERE HERE!
>>     
After that...
> ¡yes! it is as I have on file executable.sh.
>
> #!/bin/sh
> export PATH=/opt/my_project/gambas2/bin
> export GB_DIR=/opt/my_project/gambas2
> export LD_LIBRARY_PATH=/opt/my_project/gambas2/library_shared
> exec /opt/my_project/my_project.gambas
>   
I think that your LD_LIBRARY_PATH is still erroneous. The correct value 
should end with "..../usr/lib".

>> Save the changes to the file and then running:
>>
>> $ sudo ldconfig
>>     
I think that is not a good idea to fiddle with files in /etc, unless it 
is the only remaining way...
>
>> export LD_LIBRARY_PATH = / opt/my_project/gambas2/library_shared/lib: /
>> opt/my_project/gambas2/library_shared/usr/lib
>>     
Ok, this seems correct (apart from bad spaces).
ldd(1) is good to see where libraries are searched, and in fact you used 
it to find a problem. Why not use it again, after your modification to 
LD_LIBRARY_PATH? "You see an error. You do a correction. You check if 
the error has gone away". This is called debugging. Set LD_LIBRARY_PATH 
by hand, then try to do an "ls -l $LD_LIBRARY_PATH/*.so*". Then try 
again "ldd gbr2".
ldd can be run on shared libraries too: try for example "ldd 
/usr/lib/libncurses.so". May be that gbr2 finds libffi, but then libffi 
does not find something else...
Read carefully the documentation about ld.so(8). It states that if the 
program is a SETUID/SETGID one, the LD_..PATH variable is ignored. It 
says also that the variable LD_DEBUG can be set to generate verbose 
debugging - if you use this facility, by no mean you can miss the error.

I can say no more about this, but in the next messages you could first 
google-translate, and then paste citations of code and similar, which 
get messed up by google.

Hope this helps, regards,
Doriano