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

[kshegunov]

@dianyu
Yes it should. Are you linking all the assimp's dependencies? Your linker seems to have trouble finding some functions from the boost library ... Maybe try and compile assimp as a shared object, and then try to link it into your project?

Kind regards,

[dianyu]

@raven-worx Same errors... :S

[dianyu]

@kshegunov

Yes it should. Are you linking all the assimp's dependencies?

Mmm, I don't think so... I thought that as I have compiled it as static library, all the dependencies should be included inside the .a file.

Your linker seems to have trouble finding some functions from the boost library ...

I've seen this also... But it is strange. In cmake I have activated the flag to make boost workaround because i think that I don't have boost installed (At least i have no conscience of it...)

Maybe try and compile assimp as a shared object, and then try to link it into your project?

How can I specify this in xcode or cmake?

Kind regards,

Thank you a lot!

[kshegunov]

@dianyu said:

Mmm, I don't think so... I thought that as I have compiled it as static library, all the dependencies should be included inside the .a file.

Not at all, this is a common misconception. I don't really have the strength to explain it in detail, but you should link against static libraries' dependencies. Otherwise the linker will not be able to resolve the symbols. Do install boost, and link it as well. I think it is best to compile assimp as a .so, but in any case you'll still need to link against the dependencies to compile the shared object.

How can I specify this in xcode or cmake?

I have worked with neither of those, and only have a basic understanding of the cmake build cycle, so unfortunately I couldn't be of help for that. Maybe someone else will suggest the proper way.

Kind regards.

[dianyu]

@kshegunov said:

Not at all, this is a common misconception. I don't really have the strength to explain it in detail, but you should link against static libraries' dependencies. Otherwise the linker will not be able to resolve the symbols. Do install boost, and link it as well. I think it is best to compile assimp as a .so, but in any case you'll still need to link against the dependencies to compile the shared object.

How can I specify this in xcode or cmake?

I have worked with neither of those, and only have a basic understanding of the cmake build cycle, so unfortunately I couldn't be of help for that. Maybe someone else will suggest the proper way.

Kind regards.

I missunderstood you. Shared objects (dynamic libraries) in mac are .dylib. I've built them. But I can't link againts them... Linker say "library not found". I link with this code:

    LIBS += -l../Assimp-3.1.1/libassimpd.3.1.1.dylib

Anyway, I've compiled the assimp library creating a new library in my project using the .pri of assimp code inside qt3dmodule and it compiles and linkes... I needed to do some tricks in the code and link against libz.dylib. Now I should check if it works... But, I still want to make work the assimp library compiled with xcode... I linked it agains libz using (LIBS += -lz) and it didn't work... It is strage, maybe it is not working the boost workaround in the cmake?

Thanks

[kshegunov]

@dianyu
Hello,

I missunderstood you. Shared objects (dynamic libraries) in mac are .dylib

It doesn't really matter how you call them, they behave and are built similarly. On windows they are called dll's, but the principle is the same (with some very minor platform specific tweaks). I will first explain what a static library is and hopefully it will shed some light on the issue.
A static library (.a, from archive) is only a collection of translation units (.o - object files) put into one file. To create such a thing you don't really need a linker step on *nix/Linux systems, because symbol resolution is done at runtime (there are special .lib files on windows though). Now when you have a call to a function in your code an undefined symbol is created that should be resolved by the linker. When you "link" your static library the archive is appended to your application code as it would have been if you compiled the code in your application, but in no way are symbols resolved beforehand. So, if the static library references a dynamic library (e.g. libc) you have to link against it in your application, so when the loader runs it will load the libc image, and then resolve the undefined symbols (referenced in the static library OR the application). This all means, that if you have multiple dependencies in your static library they have to be met in your application (either by linking, I use this term a bit frivolously here, other static libraries or linking the dynamic libraries the static one depends on). There can be no automatic linkage performed on a static library, as it's just a collection of translation units, a static library has no notion of address space or binary compatibility, because it's just some binary code that's simply included into the final executable/shared object, and not a separate self-sustained unit. I hope this helps in understanding why you need to meet the static library's dependencies on your own.

But I can't link againts them... Linker say "library not found". I link with this code:

What about this?

LIBS += -L../Assimp-3.1.1/ -lassimpd

You should resolve the linker errors to make it work. Furthermore, qmake knows what platform you're running and knows what prefixes/suffixes are used for dynamic libraries. It also has the idea of separation between link path and library name, so maybe use the qmake link switches accordingly ...? Additionally you should check if at that location there is indeed such file present.

LIBS += -lz

Looks correct, but make sure you have installed that library and qmake can find it at the configured default link path.

Kind regards.

[dianyu]

@kshegunov said:

@dianyu
Hello,

I missunderstood you. Shared objects (dynamic libraries) in mac are .dylib

It doesn't really matter how you call them, they behave and are built similarly. On windows they are called dll's, but the principle is the same (with some very minor platform specific tweaks). I will first explain what a static library is and hopefully it will shed some light on the issue.
A static library (.a, from archive) is only a collection of translation units (.o - object files) put into one file. To create such a thing you don't really need a linker step on *nix/Linux systems, because symbol resolution is done at runtime (there are special .lib files on windows though). Now when you have a call to a function in your code an undefined symbol is created that should be resolved by the linker. When you "link" your static library the archive is appended to your application code as it would have been if you compiled the code in your application, but in no way are symbols resolved beforehand. So, if the static library references a dynamic library (e.g. libc) you have to link against it in your application, so when the loader runs it will load the libc image, and then resolve the undefined symbols (referenced in the static library OR the application). This all means, that if you have multiple dependencies in your static library they have to be met in your application (either by linking, I use this term a bit frivolously here, other static libraries or linking the dynamic libraries the static one depends on). There can be no automatic linkage performed on a static library, as it's just a collection of translation units, a static library has no notion of address space or binary compatibility, because it's just some binary code that's simply included into the final executable/shared object, and not a separate self-sustained unit. I hope this helps in understanding why you need to meet the static library's dependencies on your own.

Thank you! I have a mess in my head! :)

But I can't link againts them... Linker say "library not found". I link with this code:

What about this?

LIBS += -L../Assimp-3.1.1/ -lassimpd

Completely right.

You should resolve the linker errors to make it work. Furthermore, qmake knows what platform you're running and knows what prefixes/suffixes are used for dynamic libraries. It also has the idea of separation between link path and library name, so maybe use the qmake link switches accordingly ...? Additionally you should check if at that location there is indeed such file present.

LIBS += -lz

Looks correct, but make sure you have installed that library and qmake can find it at the configured default link path.

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

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? Another question, is there any way to check the dependencies of library?

Thanks a lot!

[kshegunov]

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

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?

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.

Kind regards.

[SGaist]

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

[dianyu]

@kshegunov said:

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