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. [SOLVED] Problem compiling/using external library (assimp)
Forum Updated to NodeBB v4.3 + New Features

[SOLVED] Problem compiling/using external library (assimp)

Scheduled Pinned Locked Moved Solved General and Desktop
28 Posts 5 Posters 17.8k Views 2 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.
  • S SGaist
    25 Jan 2016, 17:01

    There's nm available on OS X but also otool -L name_of_exec_or_librarythat will show you the dependencies

    D Offline
    D Offline
    dianyu
    wrote on 26 Jan 2016, 11:04 last edited by
    #21

    @SGaist said:

    There's nm available on OS X but also otool -L name_of_exec_or_librarythat will show you the dependencies

    Thanks! I've tried this command also with libassimpd.a but I only get the object files... Is there any way to get the library dependencies that I should indicate to the linker to be able to link it?

    Thanks a lot!

    K 1 Reply Last reply 26 Jan 2016, 15:41
    0
    • D dianyu
      26 Jan 2016, 11:04

      @SGaist said:

      There's nm available on OS X but also otool -L name_of_exec_or_librarythat will show you the dependencies

      Thanks! I've tried this command also with libassimpd.a but I only get the object files... Is there any way to get the library dependencies that I should indicate to the linker to be able to link it?

      Thanks a lot!

      K Offline
      K Offline
      kshegunov
      Moderators
      wrote on 26 Jan 2016, 15:41 last edited by kshegunov
      #22

      @dianyu
      Hello,

      I understand... So, in shared objects you don't need to indicate the linker the dependences 'cause it could find them.

      There are two sides to this. Firstly, when you compile and link the dynamic library you inform the linker of all its dependencies. Then, when you're linking it into an application (or another library) you don't do that, because that information is already written in the ELF header. Your application has a similar structure to a dynamic library - it has a header and then there is your actual (compiled) code. When you start your program the loader reads the application's header and starts loading the specified shared libraries, at the time of the loading of each of those libraries the loader does the same with each library's header and loads it's dependencies as well. You can inspect the "dependencies" of a dynamic library (or application) with ldd (assuming ldd is used on macs, hopefully @SGaist will correct me if that's not the case):

      ldd mylibrary.so
      

      Here is a bit more on the subject. Unfortunately you don't have the same capabilities for static libraries, and you either have to deduce what are the dependencies from the symbols, or, as is the usual case, just look up the vendor's site where that information should be available. If you're able to build the .a as a .so, then you could also extract the information from the last step of building - where the linker runs.

      I've tried this and the result for libassimpd.a is huge! I used grep to look for @ symbol and no results... I will investigate the man, but I'm not sure if it is what I'm looking for... I would like to know, which dependencies I need to indicate to the linker to make it work...

      Not surprising, every symbol (function, global variable etc.) will be normally listed. If you're trying to ascertain which symbols are undefined, you could grep the result to the U flag.

      Thank you very much! Your help is great!

      Thank you, I try.

      Kind regards.

      Read and abide by the Qt Code of Conduct

      D 1 Reply Last reply 27 Jan 2016, 10:14
      0
      • W Offline
        W Offline
        wwolff
        wrote on 26 Jan 2016, 19:42 last edited by
        #23

        Hi!
        I use assimp on my engine and basically instead make a lot of configurations i just get the source code , include it in a sub-project as a internal static library and works like a charm!
        Since i'm already using the zlib dependency the only thing i need to to it was some changes in the assimp main defines to inform im using a external version of zlib...

        D 1 Reply Last reply 27 Jan 2016, 10:17
        0
        • K kshegunov
          26 Jan 2016, 15:41

          @dianyu
          Hello,

          I understand... So, in shared objects you don't need to indicate the linker the dependences 'cause it could find them.

          There are two sides to this. Firstly, when you compile and link the dynamic library you inform the linker of all its dependencies. Then, when you're linking it into an application (or another library) you don't do that, because that information is already written in the ELF header. Your application has a similar structure to a dynamic library - it has a header and then there is your actual (compiled) code. When you start your program the loader reads the application's header and starts loading the specified shared libraries, at the time of the loading of each of those libraries the loader does the same with each library's header and loads it's dependencies as well. You can inspect the "dependencies" of a dynamic library (or application) with ldd (assuming ldd is used on macs, hopefully @SGaist will correct me if that's not the case):

          ldd mylibrary.so
          

          Here is a bit more on the subject. Unfortunately you don't have the same capabilities for static libraries, and you either have to deduce what are the dependencies from the symbols, or, as is the usual case, just look up the vendor's site where that information should be available. If you're able to build the .a as a .so, then you could also extract the information from the last step of building - where the linker runs.

          I've tried this and the result for libassimpd.a is huge! I used grep to look for @ symbol and no results... I will investigate the man, but I'm not sure if it is what I'm looking for... I would like to know, which dependencies I need to indicate to the linker to make it work...

          Not surprising, every symbol (function, global variable etc.) will be normally listed. If you're trying to ascertain which symbols are undefined, you could grep the result to the U flag.

          Thank you very much! Your help is great!

          Thank you, I try.

          Kind regards.

          D Offline
          D Offline
          dianyu
          wrote on 27 Jan 2016, 10:14 last edited by
          #24

          Hello,

          @kshegunov said:

          @dianyu
          Hello,

          I understand... So, in shared objects you don't need to indicate the linker the dependences 'cause it could find them.

          There are two sides to this. Firstly, when you compile and link the dynamic library you inform the linker of all its dependencies. Then, when you're linking it into an application (or another library) you don't do that, because that information is already written in the ELF header. Your application has a similar structure to a dynamic library - it has a header and then there is your actual (compiled) code. When you start your program the loader reads the application's header and starts loading the specified shared libraries, at the time of the loading of each of those libraries the loader does the same with each library's header and loads it's dependencies as well. You can inspect the "dependencies" of a dynamic library (or application) with ldd (assuming ldd is used on macs, hopefully @SGaist will correct me if that's not the case):

          ldd mylibrary.so
          

          Here is a bit more on the subject. Unfortunately you don't have the same capabilities for static libraries, and you either have to deduce what are the dependencies from the symbols, or, as is the usual case, just look up the vendor's site where that information should be available. If you're able to build the .a as a .so, then you could also extract the information from the last step of building - where the linker runs.

          There is not ldd command in mac. But there is the "otool -L " which gives that info. I've used with the dynamic version of assimp and the dependecies are libz.1.dylib, libc++.1.dylib and libSystem.B.dylib... As the second and third are c++ and system libraries I understand that I don't need to link them in the static version... So I don't know where could be the problem. I've fastly looked in the documentation and I haven't found any information about what to link... I will look it for again later more carefully.

          I've tried this and the result for libassimpd.a is huge! I used grep to look for @ symbol and no results... I will investigate the man, but I'm not sure if it is what I'm looking for... I would like to know, which dependencies I need to indicate to the linker to make it work...

          Not surprising, every symbol (function, global variable etc.) will be normally listed. If you're trying to ascertain which symbols are undefined, you could grep the result to the U flag.

          As the shared version works, I think that I will give it up... Maybe when I have more free time I try to solve it again... Anyway, thanks a lot for the help!

          K 1 Reply Last reply 27 Jan 2016, 10:20
          0
          • W wwolff
            26 Jan 2016, 19:42

            Hi!
            I use assimp on my engine and basically instead make a lot of configurations i just get the source code , include it in a sub-project as a internal static library and works like a charm!
            Since i'm already using the zlib dependency the only thing i need to to it was some changes in the assimp main defines to inform im using a external version of zlib...

            D Offline
            D Offline
            dianyu
            wrote on 27 Jan 2016, 10:17 last edited by
            #25

            @wwolff Yes I've done it also, but I have not done any change about zlib. It compiles and works. But I would like to know why I can't do it with the automatic compiled version to learn a little bit more. Assimp has not a huge number of files, but there are other libraries too big to do a .pro file everytime... Anyway, thanks a lot for the advice!

            1 Reply Last reply
            0
            • D dianyu
              27 Jan 2016, 10:14

              Hello,

              @kshegunov said:

              @dianyu
              Hello,

              I understand... So, in shared objects you don't need to indicate the linker the dependences 'cause it could find them.

              There are two sides to this. Firstly, when you compile and link the dynamic library you inform the linker of all its dependencies. Then, when you're linking it into an application (or another library) you don't do that, because that information is already written in the ELF header. Your application has a similar structure to a dynamic library - it has a header and then there is your actual (compiled) code. When you start your program the loader reads the application's header and starts loading the specified shared libraries, at the time of the loading of each of those libraries the loader does the same with each library's header and loads it's dependencies as well. You can inspect the "dependencies" of a dynamic library (or application) with ldd (assuming ldd is used on macs, hopefully @SGaist will correct me if that's not the case):

              ldd mylibrary.so
              

              Here is a bit more on the subject. Unfortunately you don't have the same capabilities for static libraries, and you either have to deduce what are the dependencies from the symbols, or, as is the usual case, just look up the vendor's site where that information should be available. If you're able to build the .a as a .so, then you could also extract the information from the last step of building - where the linker runs.

              There is not ldd command in mac. But there is the "otool -L " which gives that info. I've used with the dynamic version of assimp and the dependecies are libz.1.dylib, libc++.1.dylib and libSystem.B.dylib... As the second and third are c++ and system libraries I understand that I don't need to link them in the static version... So I don't know where could be the problem. I've fastly looked in the documentation and I haven't found any information about what to link... I will look it for again later more carefully.

              I've tried this and the result for libassimpd.a is huge! I used grep to look for @ symbol and no results... I will investigate the man, but I'm not sure if it is what I'm looking for... I would like to know, which dependencies I need to indicate to the linker to make it work...

              Not surprising, every symbol (function, global variable etc.) will be normally listed. If you're trying to ascertain which symbols are undefined, you could grep the result to the U flag.

              As the shared version works, I think that I will give it up... Maybe when I have more free time I try to solve it again... Anyway, thanks a lot for the help!

              K Offline
              K Offline
              kshegunov
              Moderators
              wrote on 27 Jan 2016, 10:20 last edited by
              #26

              @dianyu said:

              I've used with the dynamic version of assimp and the dependecies are libz.1.dylib, libc++.1.dylib and libSystem.B.dylib

              So why not explicitly link them in your application where you include your static library? Your linker error seems related to some std::string stuff missing. Maybe try something very simple like this:

              LIBS += -lz -lc++ -lSystem.B
              

              You can't break anything with linking the same library more than once, the loader will manage just fine.

              Kind regards.

              Read and abide by the Qt Code of Conduct

              D 1 Reply Last reply 28 Jan 2016, 16:14
              0
              • K kshegunov
                27 Jan 2016, 10:20

                @dianyu said:

                I've used with the dynamic version of assimp and the dependecies are libz.1.dylib, libc++.1.dylib and libSystem.B.dylib

                So why not explicitly link them in your application where you include your static library? Your linker error seems related to some std::string stuff missing. Maybe try something very simple like this:

                LIBS += -lz -lc++ -lSystem.B
                

                You can't break anything with linking the same library more than once, the loader will manage just fine.

                Kind regards.

                D Offline
                D Offline
                dianyu
                wrote on 28 Jan 2016, 16:14 last edited by
                #27

                @kshegunov said:

                @dianyu said:

                I've used with the dynamic version of assimp and the dependecies are libz.1.dylib, libc++.1.dylib and libSystem.B.dylib

                So why not explicitly link them in your application where you include your static library? Your linker error seems related to some std::string stuff missing. Maybe try something very simple like this:

                LIBS += -lz -lc++ -lSystem.B
                

                You can't break anything with linking the same library more than once, the loader will manage just fine.

                Kind regards.

                OMG! It works! Thank you very much!!!!

                K 1 Reply Last reply 28 Jan 2016, 16:55
                0
                • D dianyu
                  28 Jan 2016, 16:14

                  @kshegunov said:

                  @dianyu said:

                  I've used with the dynamic version of assimp and the dependecies are libz.1.dylib, libc++.1.dylib and libSystem.B.dylib

                  So why not explicitly link them in your application where you include your static library? Your linker error seems related to some std::string stuff missing. Maybe try something very simple like this:

                  LIBS += -lz -lc++ -lSystem.B
                  

                  You can't break anything with linking the same library more than once, the loader will manage just fine.

                  Kind regards.

                  OMG! It works! Thank you very much!!!!

                  K Offline
                  K Offline
                  kshegunov
                  Moderators
                  wrote on 28 Jan 2016, 16:55 last edited by
                  #28

                  @dianyu
                  Good luck with your project then! ;)

                  Read and abide by the Qt Code of Conduct

                  1 Reply Last reply
                  0

                  21/28

                  26 Jan 2016, 11:04

                  • Login

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