Shared lib template broken under linux ???

**fullmetalcoder** · 25th April 2006, 08: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!!!

Originally Posted by it

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

**Mike** · 25th April 2006, 09: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, 09:42

Originally Posted by fullmetalcoder

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

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:

Qt Code:

Switch view

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.

To copy to clipboard, switch view to plain text mode

or simply:

Qt Code:

Switch view

LD_LIBRARY_PATH=. ./devqt

LD_LIBRARY_PATH=. ./devqt

To copy to clipboard, switch view to plain text mode

**fullmetalcoder** · 25th April 2006, 20:03

Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!!

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, 20:22

Originally Posted by fullmetalcoder

Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!!

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:

Qt Code:

Switch view

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

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

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

To copy to clipboard, switch view to plain text mode

in MacOsX LD_LIBRARY_PATH is DYLD_LIBRARY_PATH

**wysota** · 25th April 2006, 21:13

Originally Posted by fullmetalcoder

Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!!

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, 22:43

Originally Posted by wysota

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** · 25th April 2006, 23: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, 00:09

Originally Posted by dimitri

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, 20:05

Originally Posted by wysota

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?