Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Linking internal libraries
Forum Updated to NodeBB v4.3 + New Features

Linking internal libraries

Scheduled Pinned Locked Moved Unsolved General and Desktop
24 Posts 6 Posters 7.4k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V vivaladav

    @Paul-Thexton sorry, when I wrote you last time it was pretty late and I missed testing the executable from the command line.

    You are right, it does't work and target_wrapper.sh is completely useless.

    I will look into this as I need to sort it out too, but let us know if you manage to find a proper solution :)

    P Offline
    P Offline
    Paul Thexton
    wrote on last edited by
    #15

    Thanks @vivaladav - the way I've worked around this for the time being (on Linux platform) is to explicitly build a LD_LIBRARY_PATH environment to force in to the make system.

    Obviously this is dependent on the following

    • All folders required for inclusion are at the same level
    • There are no name clashes with libraries (there never should be of course, but it's not impossible with poorly structured projects)

    If anybody finds this post who has similar problems, this is what I do to force LD_LIBRARY_PATH to contain all folders at the project top level so that "make check" works.

    export LD_LIBRARY_PATH=`find . -mindepth 1 -maxdepth 1 \! -name ".*" -type d | xargs realpath | awk '{if(NR != 1){printf ":"}printf "%s", $0} END{print ""}'`
    export TESTARGS="-o TEST.xml,xml"
    make check
    
    V 1 Reply Last reply
    2
    • P Paul Thexton

      Thanks @vivaladav - the way I've worked around this for the time being (on Linux platform) is to explicitly build a LD_LIBRARY_PATH environment to force in to the make system.

      Obviously this is dependent on the following

      • All folders required for inclusion are at the same level
      • There are no name clashes with libraries (there never should be of course, but it's not impossible with poorly structured projects)

      If anybody finds this post who has similar problems, this is what I do to force LD_LIBRARY_PATH to contain all folders at the project top level so that "make check" works.

      export LD_LIBRARY_PATH=`find . -mindepth 1 -maxdepth 1 \! -name ".*" -type d | xargs realpath | awk '{if(NR != 1){printf ":"}printf "%s", $0} END{print ""}'`
      export TESTARGS="-o TEST.xml,xml"
      make check
      
      V Offline
      V Offline
      vivaladav
      wrote on last edited by
      #16

      @Paul-Thexton nice one, even if I would recommend you to fill a bug report as things should be handled better by qmake.

      An alternative and simpler solution would be to build and link the library as static. I appreciate this might not be always what wanted, but it can be ok in many cases.

      Davide Coppola
      blog | Linkedin | Twitter

      1 Reply Last reply
      1
      • V Offline
        V Offline
        vivaladav
        wrote on last edited by
        #17

        hey @Paul-Thexton, I just noticed that Qt Creator 4.5 is not creating target_wrapper.sh any more. Can you confirm this?

        Davide Coppola
        blog | Linkedin | Twitter

        P 1 Reply Last reply
        0
        • V vivaladav

          hey @Paul-Thexton, I just noticed that Qt Creator 4.5 is not creating target_wrapper.sh any more. Can you confirm this?

          P Offline
          P Offline
          Paul Thexton
          wrote on last edited by
          #18

          @vivaladav I've just tried with Creator 4.5 and the file is still created, however I've installed it as a standalone and still using the Qt5.8.0 Kit

          I will download Qt5.10.0 later and confirm what happens, and whether my solution above is still valid - I suspect it'll be something in qmake for 5.10 that has changed.

          V 1 Reply Last reply
          0
          • K Offline
            K Offline
            karlheinzreichel
            wrote on last edited by
            #19

            Did you set your rpath dependencies with QMAKE_LFLAGS ?

            e.g.

            QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/libs\''
            QMAKE_LFLAGS += '-Wl,-rpath,\'$${QMAKE_LIBDIR_QT}\''
            
            P 1 Reply Last reply
            0
            • K karlheinzreichel

              Did you set your rpath dependencies with QMAKE_LFLAGS ?

              e.g.

              QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/libs\''
              QMAKE_LFLAGS += '-Wl,-rpath,\'$${QMAKE_LIBDIR_QT}\''
              
              P Offline
              P Offline
              Paul Thexton
              wrote on last edited by
              #20

              @karlheinzreichel yes. The problem is that qmake internally also sets the rpath for the location of the Qt libs (which can be seen in the compile output) and compilers don't seem to like two rpaths being set, I don't know the internals of linux Elf format well enough to say for certain, but it could well be that only one rpath is supported.

              1 Reply Last reply
              0
              • P Paul Thexton

                @vivaladav I've just tried with Creator 4.5 and the file is still created, however I've installed it as a standalone and still using the Qt5.8.0 Kit

                I will download Qt5.10.0 later and confirm what happens, and whether my solution above is still valid - I suspect it'll be something in qmake for 5.10 that has changed.

                V Offline
                V Offline
                vivaladav
                wrote on last edited by
                #21

                @Paul-Thexton it happens with Qt 5.10 yes, but it happened only in a project with 1 app, 1 lib and 1 unit test app.

                I will need to investigate this further, but it seems the whole target_wrapper thing is a mess at the moment.

                Davide Coppola
                blog | Linkedin | Twitter

                1 Reply Last reply
                1
                • P Offline
                  P Offline
                  Paul Thexton
                  wrote on last edited by Paul Thexton
                  #22

                  In case anybody else finds this post looking for a solution to the problem, I had a real dig around all of the Qt mkspec stuff and found the variable that needs setting to do this properly...

                  QMAKE_RPATHDIR

                  i.e.: QMAKE_RPATHDIR += $$RELATIVE_PATH_TO_SHLIB_BUILD

                  Pretty straightforward in the end, but if that answer's in the documentation anywhere then it's hidden deep :)

                  V 1 Reply Last reply
                  2
                  • SGaistS Offline
                    SGaistS Offline
                    SGaist
                    Lifetime Qt Champion
                    wrote on last edited by
                    #23

                    Hi,

                    Some more information about it QMAKE_RPATHDIR here.

                    Interested in AI ? www.idiap.ch
                    Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                    1 Reply Last reply
                    2
                    • P Paul Thexton

                      In case anybody else finds this post looking for a solution to the problem, I had a real dig around all of the Qt mkspec stuff and found the variable that needs setting to do this properly...

                      QMAKE_RPATHDIR

                      i.e.: QMAKE_RPATHDIR += $$RELATIVE_PATH_TO_SHLIB_BUILD

                      Pretty straightforward in the end, but if that answer's in the documentation anywhere then it's hidden deep :)

                      V Offline
                      V Offline
                      vivaladav
                      wrote on last edited by
                      #24

                      @Paul-Thexton it's always easy when you know the solution... ;-)

                      Thanks for sharing it!

                      Davide Coppola
                      blog | Linkedin | Twitter

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved