I have an application that needs to use a certain closed source C++ API. This API is distributed with some bits of Boost, binary library files and all. I like to use Boost in my own code. I can't just use their version of Boost since they did not distribute all the parts of Boost I need. How should I proceed? The target platform is linux, eventually Windows as well.
I won't pass Boost objects across the API boundary.
I can compile things to object files so that my code uses my boost headers, and the API's code uses its Boost headers. This part seems straightforward.
What I don't get: how to link my code to my Boost library files, and API's code to its Boost library files. Do I need to compile my own wrapper around the API -- a wrapper whose headers do not include Boost -- to a dynamic library?? (This is the only way I can think of to do the linking. The symbols in the API's Boost library files should be identical to the symbols in my Boost library files. I have to do the linking in two stages, no? The only way I can link one piece of the program without the rest is by making a dynamic library, no?)
A given executable can only have one piece of code for each symbol. So if their library uses symbol foo from boost v. 1 and you use the same symbol from boost v. 2, then you will get a clash. There's no easy way to get rid of this clash without changing the symbol. It should be possible to use dynamic execution if you were able to compile the boost code into a dynamic library, but this seems like it would be overkill.
Since, in C++, a symbol is mangled with its class/namespaces, you could also change one of these to get the symbol to change.
If you are only using the header-only boost libraries, you can just build your code separately from the code that links against the other libraries.
Which boost libraries are you using?
How does the api link with the boost library they used? They deploy a boost-##.so with it, or it was statically link?
So, please run "objdump -T api.so | grep boost" in your api .so to check if the api exposes the Boost.
Also, it is possible that they have renamed the boost namespace like the user chrisaycock mentioned. Use the c++filt command to have a closer look at the symbols you found with "objdump -T api.so | grep boost".
If it was statically linked and the boost symbols weren't exposed ( or were renamed ) then you can use boost at your code without concerning the API's boost.
If boost is really exposed, I recommend to just try using boost. To your code using boost, probably a clash won't happen. If it happens, you may compile a new boost and change your namespace name. Just run a replace-all script replacing "namespace boost" for something like "namespace boost_1_46".
Related
I'm building a executable in a big project, one of its dependency, a .so file, is linked against boost 1.6.2, and the executable itself must be static linked to a different version of boost, I don't know the version of that, maybe 1.6.0, when I link to the .so directly, it's able to compile and link, but when I run that binary, the behaviour of that binary becomes strange when calling to the functions of classes of the external .so file, such as it can run into infinite lock, and core dump inside boost. But if I don't link a different version of boost, it works. I guess the version of boost caused this problem. Is that true? How can I fix this?
The safest thing to do is to rename the namespace of your statically linked version of boost to ensure there are no symbol clashes. Unfortunately I don't think boost has any macros for changing its namespace so you'll have to do a manual find and replace in the source code.
I'm using the ASIO libraries to make a udp sending wrapper. The intent is for this to be used by another app to easily send 3 specific udp messages.
I've created a .lib file which is basically an exported utility class that wraps the ASIO functions.
To test my lib I also made a little command line app which links to my lib, creates the exported class and calls the send function.
However, the test application is requiring to link to libboost_system-vc100-mt-gd-1_55.lib but the lib file I created which actually contains the Boost code does not.
Why is this happening and how can I fix this?
A .lib file, static library, is just a grouping of object files, it's not an executable entity. It isn't linked thus it doesn't require it's unresolved symbols to be resolved.
Only the executable or shared library (DLL) that link with it need the dependencies (in this case your test code).
So there's no problem, perhaps you meant to bundle your library as a shared library rather than a static library?
Most of the boost libraries rely on boost::system because of the exception/error management is used.
boost::asio definitely uses that.
A test runner application needs to link everything as it's going to be a (statically or dynamically linked) executable, and all of the references need to be resolved.
The Boost::Asio library is available (from the same author) as a header-only standalone version.
See his think-async.com website for details, and comparison. The standalone version is useful when you do not need (or want) to have a link-time depedency on Boost. More details are on the AsioStandalone page.
FWIW I bundled this for use by R programmers as CRAN package AsioHeaders because the 'no linking' feature makes the cross-platform use particularly appealing.
You could similarly provide header-only solution for your application.
I'm working on a project written in C++ that uses the Boost Regex library to do some parsing. My problem is, I need to run the program on a remote machine that doesn't have the boost library installed. I also don't have admin access to this computer so I can't just install it myself.
Is there any way to separate out just the Boost Regex library so that I can put it in the same directory as my other code? I tried doing this already by downloading the boost library and separating out all of the unneeded headers and such. I managed to get it to a point where it calmost compiled but it failed at the linking stage.
Is there anything I can do to fix this or will I be forced to rewrite the parsing code?
You can use the Boost.BCP tool to extract a subset of Boost.
include the static library libboost_regex-gcc-1_35.a your list of object files to compile.
1_35 is an older version number on my linux box, you may have a newer library
I can't be the only one to run into this.
I have a C++ application that needs to link with one third-party and another static library set in an SDK. The SDK has, for some hideously frustrating reason, recompiled a subset of that same third-party library into their own (renamed) lib, although the symbols themselves are named the same and they are not encapsulated within a namespace. My application itself depends upon the same third-party library.
I've considered a few options, but maybe I'm missing something and hopefully a fresh look will help me out. Perhaps I'm close and someone will know the next step for one of these . I'll enumerate what I've tried and the shortcomings of each solution so far:
Link with both.
I get about 2500 lines of symbol redefinition / size change warnings and errors. This is when I first found that they defined the same symbols. I'm trying to recompile OpenSSL with g++ and drop it into a namespace at the moment...see edit below...
Link with the SDK only.
I get undefined symbols that my own code depends upon - this is when I found that their recompile of the third party lib is a subset, or at least was configured with one module disabled.
Link with the third party lib only.
I have a couple of undefined symbols reported by the SDK - one of them is actually a #define in a header file within the third party lib, so all references in the third party lib resolve to the definition, but references outside there do not. I moved that into the c file, which resolves that, however I still have two unresolved functions I can't find anywhere. This is the closest I've gotten so far.
Strip conflicting symbols from one lib and link in both.
So far this hasn't worked. It could be a version issue between the lib statically linked in the SDK and the versions I've tried using of the third-party lib, but it looks like some functions were moved between symbols, so by removing a symbol, I inadvertently remove a function that I need elsewhere. There doesn't seem to be a perfect mapping between functions in symbols in the SDK vs functions in symbols in the third-party lib. Is it plausible to strip functions without having to manually adjust addresses?
I've been examining symbols in libs with:
nm -C --defined-only lib<name>.a
And extracting entire objects with:
ar -x lib<name>.a <objname>.o
Hopefully this will also help others who have had to link with third-party libs that conflict with one another. For the sake of specifics, the third-party lib is OpenSSL, and the SDK is Opsec - libcpopenssl.a is the offending lib in Opsec.
**EDIT- A late entry possible workaround may be to recompile OpenSSL with g++ and put the whole thing in a namespace, and then link both libs. I'm trying that now...more to come...
A Google search indicate that SSL_get_peer_dh and DH_dup are really additions from libcpopenssl.a, and they don't exist in my copy of OpenSSL either. So you'll really have to link that library in. Mixing both libraries together (Approach 4 above) at binary level is unlikely to work -- OpenSSL is very picky about its ABI (they usually have .so files versioned down to the minor number) so you'd have to be very lucky to have an .so that's ABI-compatible to their .a file.
My suggestion is a variation of Approach 4, but at source level: you'll have link in the Opsec libcpopenssl.a, since it's a modified version of OpenSSL which include extra symbols (and possibly other modifications), and grab the extra functions you need from the OpenSSL sources and recompile those objects with libcpopenssl.a, so they can use the functions from the Opsec version. If you're only using a few OpenSSL functions which are not exported by libcpopenssl.a, this is quite doable.
Granted, that's still a cumbersome approach, but it's a guaranteed way to get symbol compatibility, provided of course that the Opsec SDK didn't make semantic changes to OpenSSL that will break the additional OpenSSL functions that you're pulling into your project.
(I'm new at StackOverflow so I don't know if this suggestion qualifies as a proper answer, but I don't have reputation points to post comments, anyway. I'll remove this if it's inappropriate.)
If you're morbidly curious, 249 files were modified in the most recent version of OpenSSL to get it to compile. The most common issue by far was the abundance of C-style pointer casts, particularly with void*. Now I see "reinterpret_cast" in my dreams.
This didn't solve it alone though - it still needs to be placed into a namespace in its entirety, which means modifying all of the files again as well as my own internal references to it. I think I'm going to pass on this for now.
Thanks for the help everyone.
I'm using a closed source library (by Activ financial) that includes with their API a boost distribution, both some boost header files and boost library files.
I also use Boost in my existing codebase, and I need to use Activ from my existing code.
Some points
I can encapsulate my use of Activ so that the entire Activ part amounts to a single class I wrote that does not expose any of Activ's headers
This single header file does not use any boost anything
In this way I can ensure that the Activ parts of my code use Activ's Boost HPP files, and my code uses my Boost's HPP files
My worry comes in linking. How can I ensure that my Activ dependent code links to Activ's Boost, and my other code links to my Boost?
I'm using g++ now, will also be doing this in VS2008. I got it working in VS2008 before, but I have no idea how everything linked. I want to try to make sure it's done correctly.
Is there a way to do it without further encapsulating the Activ part in a dynamic library?
Edit:
For one, my final product is always an executable file. For two, I statically link to boost myself. The Activ library includes both static and dynamic versions of Boost object libraries, and I plan to statically link it.
I never pass Boost objects between code that uses different boost versions.
The question is, how do I link one cpp or .o file to objects in one library file, and then make sure other .o files link to the identical objects in another library file? Is this possible?
Does the library dynamically or statically link to Boost? If statically linked, does the library expose the symbols in the DLL (declspec export)?
If the library is statically linked and the symbols are not exposed, and you do not pass any Boost data structures (smart_ptr, threads, etc) back and forth, you are likely safe to use your own version of the Boost library in your DLL.