[SOLVED] Problem compiling/using external library (assimp)
-
@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.libfiles 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 thelibcimage, 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/ -lassimpdYou should resolve the linker errors to make it work. Furthermore,
qmakeknows 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 += -lzLooks correct, but make sure you have installed that library and
qmakecan find it at the configured default link path.Kind regards.
@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.libfiles 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 thelibcimage, 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/ -lassimpdCompletely right.
You should resolve the linker errors to make it work. Furthermore,
qmakeknows 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 += -lzLooks correct, but make sure you have installed that library and
qmakecan 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!
-
@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 += -lzshould 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 (throughrpathfield in the ELF, or theLD_LIBRARY_PATHenvironment 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
nmlike this:nm -C mylibrary.soI 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_clonesNote the undefined
qt_version_tagfrom Qt 5.6 and the weak__cxa_finalizethat is referencing GLIBC 2.2.5! An explanation for the letters' meaning is available through themanpages.Kind regards.
-
There's nm available on OS X but also
otool -L name_of_exec_or_librarythat will show you the dependencies -
@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 += -lzshould 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 (throughrpathfield in the ELF, or theLD_LIBRARY_PATHenvironment 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
nmlike this:nm -C mylibrary.soI 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_clonesNote the undefined
qt_version_tagfrom Qt 5.6 and the weak__cxa_finalizethat is referencing GLIBC 2.2.5! An explanation for the letters' meaning is available through themanpages.Kind regards.
@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 += -lzshould 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 (throughrpathfield in the ELF, or theLD_LIBRARY_PATHenvironment 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
nmlike this:nm -C mylibrary.soI 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_clonesNote the undefined
qt_version_tagfrom Qt 5.6 and the weak__cxa_finalizethat is referencing GLIBC 2.2.5! An explanation for the letters' meaning is available through themanpages.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!
-
There's nm available on OS X but also
otool -L name_of_exec_or_librarythat will show you the dependencies@SGaist said:
There's nm available on OS X but also
otool -L name_of_exec_or_librarythat will show you the dependenciesThanks! 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!
-
@SGaist said:
There's nm available on OS X but also
otool -L name_of_exec_or_librarythat will show you the dependenciesThanks! 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!
@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(assuminglddis used on macs, hopefully @SGaist will correct me if that's not the case):ldd mylibrary.soHere 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
.aas 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
grepthe result to theUflag.Thank you very much! Your help is great!
Thank you, I try.
Kind regards.
-
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,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(assuminglddis used on macs, hopefully @SGaist will correct me if that's not the case):ldd mylibrary.soHere 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
.aas 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
grepthe result to theUflag.Thank you very much! Your help is great!
Thank you, I try.
Kind regards.
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(assuminglddis used on macs, hopefully @SGaist will correct me if that's not the case):ldd mylibrary.soHere 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
.aas 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
grepthe result to theUflag.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!
-
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...@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!
-
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(assuminglddis used on macs, hopefully @SGaist will correct me if that's not the case):ldd mylibrary.soHere 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
.aas 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
grepthe result to theUflag.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 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.BYou can't break anything with linking the same library more than once, the loader will manage just fine.
Kind regards.
-
@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.BYou can't break anything with linking the same library more than once, the loader will manage just fine.
Kind regards.
@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.BYou 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 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.BYou 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!!!!
