Setting LD_LIBRARY_PATH from Qt Creator

[spud]

Hi all,
I'm having problems with something that should be very easy.
I have a project which creates a dynamic library and an executable. So far I have only compiled it on Windows and I use the following setup:



#Library pro file
TEMPLATE = lib
DESTDIR = ../lib
DLLDESTDIR = ../bin
DEFINES += CREATE_DLL
CONFIG += debug_and_release

build_pass:CONFIG(debug, debug|release) {
TARGET = $$join(TARGET,,,d)
}




#Application pro file
TEMPLATE = app
DESTDIR = ../bin
LIBS += -L../lib
CONFIG += debug_and_release

CONFIG(release, debug|release){
LIBS += -lMyLib
}
build_pass:CONFIG(debug, debug|release){
TARGET = $$join(TARGET,,,d)
LIBS += -lMyLibd
}


Now I want to debug the application on Linux with Qt Creator. I'm using Ubuntu.

I load the project into Creator and I can compile it just fine in debug or relase mode. The problem arises when I want to launch the application.

Failed to start program. Path or permissions wrong?
I can start the app from a terminal if I call

export LD_LIBRARY_PATH=/path/to/lib
ldconfig

But setting LD_LIBRARY_PATH from within Qt Creator has no effect.
I could of course fix it by setting LD_LIBRARY_PATH globally before I start Qt Creator, but that isn't convinient, since I have a lot of projects with the same setup.

So I was wondering if someone could tell me what the cannonical way is to set up your pro files for a project using dynamic libs(in a portable way). None of the examples or demos from Qt use dynamic libs(not counting plugins, since they're a differnt story alltogether).

I'm greatful for any help and apologize beforehand for my linux noobishness.

[spirit]

settings LD_LIBRARY_PATH in a project's "environment settings" in Qt Creator should work fine. I did not get any troubles with this.

[spud]

Oh I spoke too soon,
setting LD_LIBRARY_PATH actually works. The problem is that Creator ignores the following line

TARGET = $$join(TARGET,,,d)
and tries to launch MyApp instead of MyAppd even when I've chosen the debug configuration.

It would seem like Creator doesn't support different names for debug and release builds.

[zeFree]

[ I know that I am a bit (perhaps completely) off the topic of this thread, but please help me getting to the right thread and the right solution. ]

Hello spirit and spud,

I am a COMPLETE NOOB when it comes to deploying apps with Qt.
I am trying to become a "Cross-platform" (Qt) Developer - but deploying always stops me from going anywhere.
The only place where I have successfully deployed my Qt apps are on Windows - because I just have to:

- build the app with release configuration

- copy the file in a folder on a non-Qt (virtual) machine

- then run the app

- now, as app runs every time it asks for some .dll file

- keep copying the .dll files in folder until finally the app gets all what it needs and it finally runs - as it should.


Now, :( this is my first time with deploying on Linux (mine is Ubuntu 10.10); and it's making me crazy like HELL!!!:mad:
I tried the same trick (which I use in Windows) but it didn't work at all - because the app when run on a non-Qt (virtual) machine doesn't run AT ALL.:confused: WTF(ish) man!!!
Then I studied a bit and learned about stuff like:

LD_LIBRARY_PATH
ldd on unix

and now trying to use it... but alas... no help with this stuff!!!
I am going into depression and thinking of using Processing(.org) instead of Qt as deploying in it is really just a matter of clicks --- as actually it should have been in Qt --- otherwise of what good use is a cross-platform development thing - if I can't deploy it - EASILY. :(

See - how easy it is on Processing: http://youtu.be/rJrh0RipoVo?t=2m20s

Why can't the Qt guys do this???

Please help me. I am the noob you guys are the man! the experts! Please help me.

Regards,
zefree

[ChrisW67]

Could some kind moderator split this post into a new (newbie) thread rather than leaving it tacked on the end of a two year old thread?

Your process on Windows is to run it to failure, add the missing DLLs, repeat until it works. This approach is not elegant and relies on built in error handling, that is often not present, to tell you what to copy next. You could a similar process on Linux or OS X. By using "ldd" on your executable you obtain a list of all the libraries the application requires to start up-front, and without having to run the program at all (depends.exe does a similar thing on Windows). Then you just have to make sure those libraries marked missing are available in the places the operating system will look for them, or adjust where the OS will look. You might still have to chase down Qt Plugins, but that problem is no different to Windows.

Some understanding about your program's dependencies and how the operating system locates dynamically loaded libraries at run time is required to deploy any application: this is neither Qt-specific nor a failing of Qt.

On Windows the directory containing the executable and the current working directory are searched when a DLL is to be loaded (http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx). On Windows, therefore, just dropping Qt DLLs next to the application is adequate.

On Linux, and other UNIX-like systems, the program directory and current working directory are very rarely in the system default search path for libraries (for security reasons), but a mechanism is provided to locally change the library search path if needed. Most Linux systems have Qt installed or have an easily installed Qt package, in which case you need do nothing other than install it. If you need a particular Qt version, or a program that runs independently of a system copy of Qt, then you drop the Qt libraries you need in a folder (any folder including the one containing your app) and use LD_LIBRARY_PATH in a simple wrapper script to start your application. Unsurprisingly, this is explained in the documentation shipped with Qt. Google Earth on Linux uses this method if you want a "real" example.