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

[dianyu]

@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!

[kshegunov]

@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.

[wwolff]

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...

[dianyu]

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!

[dianyu]

@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!

[kshegunov]

@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.

[dianyu]

@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!!!!

[kshegunov]

@dianyu
Good luck with your project then! ;)