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

[EA7DFH]

Doriano Blengino escribió:

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

Hi

Moreover, I think you lost the symbolic links of the shared libraries
when it has been moved/copied to your custom folder in /opt/.../...

May be it is your main problem. Look at my tree command output:

jesus at ...2151...:/usr/lib$ tree | grep libffi
|-- libffi.a
|-- libffi.so -> libffi.so.5.0.8
|-- libffi.so.5 -> libffi.so.5.0.8
|-- libffi.so.5.0.8
|-- libffi_pic.a
|   |-- libffi.pc
jesus at ...2151...:/usr/lib$

Do you notice the "->" symbol pointing to the target lib?

Therefore, libffi.so and libffi.so.5 are only symlinks pointing to
libffi.so.5.0.8 and it seems they aren't in place.

Hope this helps a little,

regards.

Jesús Guardon