Undefined reference to third party library functions in linking static library
I created my static library dependent on third party library (boost::filesystem etc) by using CMake (add_library(...)).
When the library will be used and linked in other project,
there appears error of undefined reference to functions of dependent third party libraries.
How to incorporate third party's definition into a single static library file(xxx.a) without user-side linking to the third party?
Or is it impossible?
When the library will be used and linked in other project,
there appears error of undefined reference to functions of dependent third party libraries.
How to incorporate third party's definition into a single static library file(xxx.a) without user-side linking to the third party?
Or is it impossible?
Last edited on
I think it is possible, but I gave up on CMake for exactly these kinds of problems. You will have to dig deep in the documentation and/or ask over on a CMake forum. (I’m pretty sure one of these still exists...)
https://www.google.com/search?q=cmake+forum
Sorry I can’t help better. Perhaps someone else here will know better... but I wouldn’t necessarily hold my breath. Alas.
https://www.google.com/search?q=cmake+forum
Sorry I can’t help better. Perhaps someone else here will know better... but I wouldn’t necessarily hold my breath. Alas.
Dear Duthomhas
Thank you for your comment.
I am also sometimes aware that CMake is cumbersome.
(Powerful C++ libraries depends on it, which constraints me)
Anyway, I appreciate your opinion, thanks a lot.
Thank you for your comment.
I am also sometimes aware that CMake is cumbersome.
(Powerful C++ libraries depends on it, which constraints me)
Anyway, I appreciate your opinion, thanks a lot.
CMake manages this just fine:
https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/Exporting-and-Importing-Targets
https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/Exporting-and-Importing-Targets
Last edited on
A few things strike me on this question.
First, filesystem became part of C++, so it should be fairly straightforward to transfer from boost to the standard library for that one.
That means a lot depends on the "etc", because some of those may be header only and would be automatically incorporated in the static library, or user code, as required.
A few boost libraries that are "built", instead of header only, are actually header libraries dependent on some built library, with options. The details escape me at the moment, so I offer what I vaguely remember on this point, but some library required (I think) date-time (perhaps chrono from boost). There was an option to strip down that dependency to header only, so ultimately the dependency did not actually require static library content from boost when some particular define was set.
So, faced with this question I would first review that the boost libraries selected are, with certainty, not now available in the standard library. There are arguments about sticking with boost, usually based on avoiding C++17 or even C++14 dependency, but soon (if not now) that argument fades from relevancy.
On another front, I contemplate the various combinations of ABI/binary compatibility among all the various compilers a consumer might choose across all the platforms to be supported, and eventually end up thinking it isn't worth the trouble.
That is to say, I've used a number of libraries which consumed boost, and so far I don't recall any that did not require I had boost installed and built.
In particular, if your static library product has any header which uses boost headers such that the consumer of this library would have to have boost, there's really no reason not to let them use their boost and avoid all issues attempting to solve this problem.
If you've carefully scrubbed all mention of boost includes in the headers your consumers use to incorporate your static library in their code, you do have a chance to incorporate the boost binary materials, but I find this is much simpler on Windows than *Nix. While MAC could use gcc, I think most MAC programmers are going to use CLang (as supplied by Apple), which may be simplifying on OS X.
@mbozzi's right, CMake can do this, but this requires familiarity with CMake, and as much as I use it, I'm with @Duthomhas here - I really don't want to be a CMake student, so I'd just try hard to avoid there being a problem at all by ensuring that I move toward the standard libraries for (former) boost services, and veer toward boost's header only libraries for a situation like you describe.
First, filesystem became part of C++, so it should be fairly straightforward to transfer from boost to the standard library for that one.
That means a lot depends on the "etc", because some of those may be header only and would be automatically incorporated in the static library, or user code, as required.
A few boost libraries that are "built", instead of header only, are actually header libraries dependent on some built library, with options. The details escape me at the moment, so I offer what I vaguely remember on this point, but some library required (I think) date-time (perhaps chrono from boost). There was an option to strip down that dependency to header only, so ultimately the dependency did not actually require static library content from boost when some particular define was set.
So, faced with this question I would first review that the boost libraries selected are, with certainty, not now available in the standard library. There are arguments about sticking with boost, usually based on avoiding C++17 or even C++14 dependency, but soon (if not now) that argument fades from relevancy.
On another front, I contemplate the various combinations of ABI/binary compatibility among all the various compilers a consumer might choose across all the platforms to be supported, and eventually end up thinking it isn't worth the trouble.
That is to say, I've used a number of libraries which consumed boost, and so far I don't recall any that did not require I had boost installed and built.
In particular, if your static library product has any header which uses boost headers such that the consumer of this library would have to have boost, there's really no reason not to let them use their boost and avoid all issues attempting to solve this problem.
If you've carefully scrubbed all mention of boost includes in the headers your consumers use to incorporate your static library in their code, you do have a chance to incorporate the boost binary materials, but I find this is much simpler on Windows than *Nix. While MAC could use gcc, I think most MAC programmers are going to use CLang (as supplied by Apple), which may be simplifying on OS X.
@mbozzi's right, CMake can do this, but this requires familiarity with CMake, and as much as I use it, I'm with @Duthomhas here - I really don't want to be a CMake student, so I'd just try hard to avoid there being a problem at all by ensuring that I move toward the standard libraries for (former) boost services, and veer toward boost's header only libraries for a situation like you describe.
Last edited on
Topic archived. No new replies allowed.