Link library

  • Hi
    "On this site": below Linux it says to:
    Now why i stil get a dlerror with the *.pro file below?

    unix:!macx {
    INCLUDEPATH += ../SDK/CHeaders/XPLM;../SDK/CHeaders/Widgets;../SDK/CHeaders/Wrappers;./
    QMAKE_LFLAGS += -g -Wl,-rpath,\$$ORIGIN

    There are headers in the same directory as the main.cpp and in folders below.
    Many thanks

  • What is the exact compiler / linker error?
    Have you added the library path?
    Does LIBS += -L<library path> -l<library> not work?

    -Wl,-rpath looks like a compiler option, not a linker option.
    QMAKE_CXXFLAGS has to be used for compiler options, QMAKE_LFLAGS for linker options.

  • if I do: LIBS += -L<library path> -l<library> it compils but says lib not found at execution.
    So I need $ORIGIN somehow? Also I suspect this not being GPL compliant. The author of the gpl lib told me ok but to link alike below:
    "Link here":

    anyway how to link(or not as above) a closed source to a gpl lib?
    Thanks again Michael

  • Do you link against a static or a shared library? The latter one requires you to distribute the shared library along with your application.

    When your application starts up it (or more specific the runtime linker) looks for the required shared libraries within the runtime library search path list. With the -rpath option you can add a path to this list at link time.

    You can link a GPL library to a closed source application as any other library - but you are not allowed to do so (independent of static or shared linkage) unless you get permission from the licensor.

  • As i've the source of the lib I could probably compile either but default seems as shared lib. So linking as shared lib with the authors permission is ok? Ok and what's wrong with?
    QMAKE_LFLAGS += -g -Wl,-rpath,\$$ORIGIN
    only LIBS += -L<library path> -l<library> is working but not found at runtime. I have the lib in the same directory as the executable.

    Hope that the author doesn't change mind and decides to sue me in some years...

  • You cannot use "GPL": code in a closed source project without permission of the licensor. Period.

    You will need a license contract - preferably written, signed by both parties and under survey of legal advice - for everything else further than that.

    Releasing software which uses intellectual property of someone other than you will have legal consequences you will have to deal with.

    bq. The programs and* find and load the shared libraries needed by a program, prepare the program to run, and then run it.

    bq. The shared libraries needed by the program are searched for in the following order:

    • (ELF only) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated.
    • Using the environment variable LD_LIBRARY_PATH. Except if the executable is a set-user-ID/set-group-ID binary, in which case it is ignored.
    • (ELF only) Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present.
    • From the cache file /etc/ which contains a compiled list of candidate libraries previously found in the augmented library path. If, however, the binary was linked with the -z nodeflib linker option, libraries in the default library paths are skipped.
    • In the default path /lib, and then /usr/lib. If the binary was linked with the -z nodeflib linker option, this step is skipped.

    bq. understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath specification (DT_RPATH or DT_RUNPATH) to mean the directory containing the application executable. Thus, an application located in somedir/app could be compiled with gcc -Wl,-rpath,aq$ORIGIN/../libaq so that it finds an associated shared library in somedir/lib no matter where somedir is located in the directory hierarchy. This facilitates the creation of "turn-key" applications that do not need to be installed into special directories, but can instead be unpacked into any directory and still find their own shared libraries.

    -Wl,-rpath is a compiler option, not a linker option. You will have to use QMAKE_CXXFLAGS instead.-

    Your shared library has to be placed

    • in a directory in the LD_LIBRARY_PATH environment variable or
    • /lib, /usr/lib or any other system-specific global library search path or
    • in a directory specified at the -rpath linker option

  • [quote author="Lukas Geyer" date="1312976241"]-Wl,-rpath is a compiler option, not a linker option. You will have to use QMAKE_CXXFLAGS instead.[/quote]Actually, it's a linker option when g++ is used as the linker command: all options beginning with "-Wl" are used only in the linking stage.
    So he can use QMAKE_LFLAGS or LIBS (or QMAKE_RPATH but I don't know if it works as expected).

  • So I'll try $ORIGIN later again. Now I think the author meant to have his gpl lib, modified and running as x-plane plugin. That way I could dynamically access those functions from my own x-plane plugin running aside without linking? Would such make sense and be GPL conform? I have to investigate if such is even technically possible...

  • "Can I release a non-free program that's designed to load a GPL-covered plug-in?":

    Yes, there might be combinations which allow for using GPL code within closed source projects, but...

    The licensor wants you to contribute if you benefit - this is the reason why he had chosen the GPL in the first place. If he wanted that his code can be used in closed source applications he wouldn't have chosen the GPL or will grant you a more permissive license. So it doesn't matter how technically or legally sophisticated your solution is - it is against the licensors intention and therefore unethical and illegal.

    Just ask yourself: does you product require the GPL code to function?

    Personal view, IANAL!

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.