PDA

View Full Version : Shared lib template broken under linux ???



fullmetalcoder
25th April 2006, 09:35
Hi,

A project of mine is splitted in two components : an executable and a shared lib. It compiles and run fine under window$ (mingw3.4.2, win ME) but when I tried to compile it under my linux distro (Kanotix 2005-4, GCC 4.0.1) the .so occured to cause troubles...

Firts of all I believed that any shared lib neede an import lib (.a in my case) but none was created... Thus I had to change my project file but it finally compiled fine. Second step : running the app. My executable is in the same directory as my .so, the makefile created 3 symlinks to it to make sure it can't get lost...
And the executable doesn't find the library!!! :confused:

error while loading shared libraries: libdevqt.so.1: cannot open shared object file: No such file or directory

I tried changing the name of the real shared library to avoid troubles with symlinks but it didn't change anyhting!
Help me!!! :crying:

Mike
25th April 2006, 10:36
hmm... would it help if you provide the .pro files?

I use the QPluginLoader class for my project and so far have no problems with main app loading the plugin on Windows or Linux.

Mike

wysota
25th April 2006, 10:42
Firts of all I believed that any shared lib neede an import lib (.a in my case) but none was created...
Only crappy OSes need it.


Second step : running the app. My executable is in the same directory as my .so, the makefile created 3 symlinks to it to make sure it can't get lost...
And the executable doesn't find the library!!! :confused:

I tried changing the name of the real shared library to avoid troubles with symlinks but it didn't change anyhting!

Linux doesn't look for libraries in the "current directory". You have to tell it where to look for the lib. For example by issuing:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.

or simply:


LD_LIBRARY_PATH=. ./devqt

fullmetalcoder
25th April 2006, 21:03
Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!! :p
Is there a way to do that programmatically because I don't wanna force each user of my app to do that stupid trick on its own... I think there some QApplication static functions that deals with library paths but will they work from the application itself or will loading fail before the static function is called???

krawek
25th April 2006, 21:22
Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!! :p
Is there a way to do that programmatically because I don't wanna force each user of my app to do that stupid trick on its own... I think there some QApplication static functions that deals with library paths but will they work from the application itself or will loading fail before the static function is called???

Predefined library path avoid security problems, for launch application write a simple script:



#!/bin/bash
export DEVQT_HOME=/path/to/data/files/
export LD_LIBRARY_PATH=${DEVQT_HOME}/lib

#and launch app
${DEVQT_HOME}/bin/devqt



in MacOsX LD_LIBRARY_PATH is DYLD_LIBRARY_PATH

wysota
25th April 2006, 22:13
Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!! :p
If the loader was looking in the current dir for libraries, it would be trivial to poison any application by using a "modified" version of a library it uses. There are even viri/rootkits for Linux that use this and ld_preload mechanism to infect the system. If a user wants to alter the library path, it has to be her/his own decision.

dimitri
25th April 2006, 23:43
If the loader was looking in the current dir for libraries, it would be trivial to poison any application by using a "modified" version of a library it uses.
Actually isn't this a misundesrtanding? As far as I know, on Windows the loader looks for DLLs in the application directory, not the current directory. This looks like a good idea and I don't think there are related security issues.

wysota
26th April 2006, 00:10
What if you make a link to the application and somehow force the directory containing the link to be in the path before the directory containing the proper binary (without a poisoned lib in the same directory) or even execute the link yourself on purpose? Making a hard link (I don't know what about a symbolic one) will surely change the "application directory" which opens the security hole again.

krawek
26th April 2006, 01:09
Actually isn't this a misundesrtanding? As far as I know, on Windows the loader looks for DLLs in the application directory, not the current directory. This looks like a good idea and I don't think there are related security issues.
Windows? ...

dimitri
26th April 2006, 21:05
What if you make a link to the application and somehow force the directory containing the link to be in the path before the directory containing the proper binary (without a poisoned lib in the same directory) or even execute the link yourself on purpose? Making a hard link (I don't know what about a symbolic one) will surely change the "application directory" which opens the security hole again.
This cannot happen on Windows, can it?