I would like to use the -rpath linker option to set the .so search path. I'd like it to search [app_path]/../lib. I've tried add this to my qmake .pro file:
QMAKE_LFLAGS += -Wl,-rpath=$ORIGIN/../lib/
But qmake links my project this way:
g++ -Wl,-rpath=RIGIN/../lib/ -Wl,-O1 -o myoutput main.o [...]
How can I escape the $ORIGIN?
I found here a way to properly escape it:
QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/../mylibs\''
If you want $ORIGIN to be (properly) evaluated while building you can simply add this to your .pro file:
QMAKE_RPATHDIR += $ORIGIN/../mylibs
This is a really old question, but for people getting here through a search: the methods described in the old answers are not needed anymore. Modern Qt versions (5.9 in my case), allow you to just use this:
QMAKE_RPATHDIR += lib
This will add the needed entries (including $ORIGIN and -Wl,-z,origin where needed) automatically to the makefile, as long as you're using a relative directory. Meaning that lib will produce the needed "origin" entries, while something like /lib will not. Any relative directory you add to QMAKE_RPATHDIR will be made relative to $ORIGIN automatically.
DOLLAR=$
QMAKE_LFLAGS += -Wl,-rpath=$${DOLLAR}$${DOLLAR}ORIGIN/../myLibs
Related
My .pro file has extra stuff in it:
win32 {
OUT_PWD_SHELL = $$replace(OUT_PWD, /, \\)
autoversion.target = $$OUT_PWD\\autoversioninfo.h
autoversion.depends = FORCE
autoversion.commands = $$PWD/../../AutoBuildVersion.exe $$replace(PWD, /, \\) $$OUT_PWD_SHELL
QMAKE_EXTRA_TARGETS += autoversion
PRE_TARGETDEPS += $$OUT_PWD\\autoversioninfo.h
}
This fails to work as expected because in the generated makefile DESTDIR_TARGET has a new dependency added that starts d:\ but the rule generated for autoversion starts with D:/. I can improve this slightly by replacing all / with \, but the case sensitivity still breaks it and the target is not built.
If I remove the full path from autoversion.target and PRE_TARGETDEPS then it solves that problem, but then when calculating dependencies, the rule for the cpp file that includes the generated header changes to give an explicit path to the header in the dependencies, and that path points to the source directory and not the output directory where the generated file is produced. This causes make to barf and not produce the generated file.
I don't know why qmake changes the case handling of the drive, it is very irritating, but how do I get this all to work correctly?
There is no good solution. The best I came up with is to use a phony target that always runs to generate the header file. On the downside this slows the build when the header file already exists, but on the upside, it allows the build to complete.
win32 {
OUT_PWD_SHELL = $$replace(OUT_PWD, /, \\)
gen_autoversion.target = GENERATE_AUTOVERSIONINFO
gen_autoversion.commands = $$PWD/../../AutoBuildVersion.exe $$replace(PWD, /, \\) $$OUT_PWD_SHELL
QMAKE_EXTRA_TARGETS += gen_autoversion
PRE_TARGETDEPS += GENERATE_AUTOVERSIONINFO
}
I am not sure that PRE_TARGETDEPS is actually needed here.
I have a qmake project that looks like this:
TEMPLATE = lib
CONFIG += dll
TARGET = mydll
SOURCES += ...
HEADERS += ....
Now I want to add an INSTALLS section, so I have:
target.path = /path/to/somedir/
target.files =./$$TARGET
INSTALLS+= target
Unfortunately this will not work, because $$TARGET contains the target name, and not the output file name. Is there a portable way to obtain the output file name? (Please no platform dependent string concatenation like lib + $$TARGET + .so)
You don't have to specify target.files, target is a special case and it's predefined in qmake.
http://qt-project.org/doc/qt-4.8/qmake-environment-reference.html#installs
If you append a built-in install set to the INSTALLS variable and do not specify files or extra members, qmake will decide what needs to be copied for you. Currently, the only supported built-in install set is target:
target.path = /usr/local/myprogram
INSTALLS += target
In the above lines, qmake knows what needs to be copied, and will handle the installation process automatically.
Sorry for asking this newbie question but I can't get off this s***t...
In the same directory I have 4 files : ctacs.ini; ct_api.h; libctacs.a and main.cpp.
My cpp file contains #include "ct_api.h" and when I try to compile with :
g++ -lctacs main.cpp -o main
I got undefined references to the functions which are defined in my library -__-
Could you please tell what did I wrong ? I search on the internet but the option -lctacs seems to be the right way to proceed...
Thank you very much
Some compilers and linkers resolve references to functions by searching the object files/sources files/libraries left-to-right on the command line. This means that files that call externally-defined functions should appear before the object files/libraries/source files that contain their definitions.
You happen to have a linker that does indeed depend on this ordering. You need to put the library after main.cpp so that the function definitions can be found:
g++ main.cpp -lctacs -o main
I need to include a binary program in my project. I use objcopy to create an object file from a binary file. The object file can be linked in my program. objcopy creates appropriate symbols to access the binary data.
Example
objcopy -I binary -O elf32-littlearm --binary-architecture arm D:\Src\data.jpg data.o
The generated symbols are:
_binary_D__Src_data_jpg_end
_binary_D__Src_data_jpg_size
_binary_D__Src_data_jpg_start
The problem is that the symbols include the path to the binary file D__Src_. This may help when binary files are included from different location. But it bothers me that the symbols changes when I get the file from a different location. Since this shall run on several build stations, the path can't be stripped with the --redefine-sym option.
How do I get rid of the path in the symbol name?
I solved this problem by using this switch in objcopy:
--prefix-sections=abc
This gives a way to uniquely identify the data in your binary object file (ex. binary.o)
In your linker script you can then define your own labels around where you include the binary.o. Since you are no longer referencing anything in binary.o the binary will be thrown out by the linker if you use -gc-sections switch. The section in binary.o will now be abc.data. Use KEEP in your linker script to tell the linker not to throw out binary.o. Your linker script will contain the following:
__binary_start__ = .;
KEEP(*(abc.data))
binary.o
*(abc.data)
. = ALIGN(4);
__binary_end__ = .;
The switch --localize-symbols works for me.
I'm making a project which uses lots of it's own shared libraries; my intention is to create a library name within a directory, so, e.g., instead of -lfoo (to find /usr/lib/libfoo.so or /opt/lib/libfoo.so or so on), I would use -lfoo/bar (to find /usr/lib/libfoo/bar.so or /opt/lib/libfoo/bar.so or so on).
I made a real small code to test:
const char *mylib(void) {
return "it woooorks! =D";
};
And compiled it with: gcc -fPIC -shared -Wl,-rpath,libfoo/ lib.c -o /usr/lib/libfoo/bar.so.
Then, in the test program, I use gcc -lfoo/bar test.c, and it compiles (it finds the mylib() symbol from my library), but when I try to run the program (./a.out), the dynamic linker complains that it can't find the library. In my case, using Mac OS X Lion:
dyld: Library not loaded: bar.so
Referenced from: /Users/takanuva/tmp/lib/./a.out
Reason: image not found
Trace/BPT trap: 5
What am I doing wrong? Maybe the answer is "everything", so... how should I accomplish the desired effect, to look for libfoo/bar.so instead of libfoo.so on the library paths?
Thanks in advance. :)
If the library is not located in a standard path (and /opt is such a path that is normally not searched), you must specify the paths with -L/-rpath, as in gcc blah.c -L/opt/whatever -Wl,-rpath,/opt/whatever -lbar. Do NOT attempt to use path separators in the -l argument.