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

SGaist

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

dianyu

@dianyu
Hello,

It is because it is installed in the /usr/lib folder.

This should be in your default link-path as far as I can tell, so in all probability LIBS += -lz should be just enough.

Yep!

I've used the dynamic library (without boost) and it works. It compiles and links without errors. Then, my doubts are why it works for the dynamic library and not for the static one? The dependencies should be at least the same, isn't it?

The shared object is supposed to be shared, so it has a header that tells ld, the linker that is, what other binaries to load and possibly (through rpath field in the ELF, or the LD_LIBRARY_PATH environment variable) where to find those dependencies. A static library, as already established, has no such thing and has no compatible capabilities. I think this should answer it?

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

Another question, is there any way to check the dependencies of library?

Whenever I need to look up the symbol table I personally use nm like this:

nm -C mylibrary.so

I don't often do that, and I have no idea whatsoever if it's available to macs, since I've never worker on such machines, but I suppose it should be possible to use it. This command will produce something similar to this:

0000000000200968 d __TMC_END__                                                                                                                                                                                                                             
0000000000200968 B __bss_start                                                                                                                                                                                                                             
                 w __cxa_finalize@@GLIBC_2.2.5                                                                                                                                                                                                             
0000000000000630 t __do_global_dtors_aux                                                                                                                                                                                                                   
0000000000200708 t __do_global_dtors_aux_fini_array_entry                                                                                                                                                                                                  
0000000000200960 d __dso_handle                                                                                                                                                                                                                            
0000000000200700 t __frame_dummy_init_array_entry                                                                                                                                                                                                          
                 w __gmon_start__                                                                                                                                                                                                                          
0000000000200968 D _edata                                                                                                                                                                                                                                  
0000000000200970 B _end                                                                                                                                                                                                                                    
00000000000006a0 T _fini                                                                                                                                                                                                                                   
0000000000000560 T _init                                                                                                                                                                                                                                   
0000000000200968 b completed.6971                                                                                                                                                                                                                          
00000000000005a0 t deregister_tm_clones                                                                                                                                                                                                                    
0000000000000670 t frame_dummy                                                                                                                                                                                                                             
                 U qt_version_tag@@Qt_5.6                                                                                                                                                                                                                  
00000000000005e0 t register_tm_clones

Note the undefined qt_version_tag from Qt 5.6 and the weak __cxa_finalize that is referencing GLIBC 2.2.5! An explanation for the letters' meaning is available through the man pages.

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

Kind regards.

Thank you very much! Your help is great!

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! ;)