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: je...@jesus:/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 je...@jesus:/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 ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
