First off I know there are several posts similar to this,but I am going to ask anyway. Is there a known problem with boost program_options::options_description in Debian "Buster" and Boost 1.67 packages?
I have code that was developed back in Debian 7, system upgraded to 8.3 then 8.11 now using Boost 1.55.
Code builds and runs. Now upgrade system to Debian Buster with Boost 1.67 and get the link errors for unresolved reference to options_description(const std::string& , unsigned int, unsigned int) along with several other program_options functions. All unresolved, expect the options_description, are from boost calling another boost function, so not even directly called from within my code. boost_program_options IS in the link line.
I AM not a novice and understand link order and this has nothing to do with link order.
I am going to try getting the source code for boost and building to see if that works, if not I will be building a system from scratch and testing against that.
Since this is all on a closed network simply saying try a newer version of boost or Debian is not an option because I am contractually obligated to only use Debian "Buster" and Boost 1.67 as the newest revisions, so if the package is unavailable (newer) in Buster it is out of the question, without having a new contract be drafted and go through approvals which could take months.
So to the point of this question, is there an issue with the out of the box version of Boost in Buster?
I don't think there's gonna be an issue with the package in Buster.
My best bet is that either
you're relinking old objects with the new libraries - and they don't match (did you do a full make clean e.g. to eliminate this possibility?).
Often build systems do not do complete header dependencies, so the
build system might not notice that the boost headers changed,
requiring the objects to be be rebuilt.
if that doesn't explain it, there could be another version of boost on the include path, leading to the same problem as under #1 even when rebuilding.
You could establish this by inspecting the command lines (make -Bsn or compile_commands.json e.g. depending on your tools). Another trick is to include boost/version.hpp and see what BOOST_VERSION evaluates to
Lastly, there could be a problem where the library was built with different compiler version or compiler flags, leading to incompatible synbols (this is a QoI issue that you might want to report with the Boost Developers).
This is assuming ABI/ODR issues, in case you want to validate this possibility.
Related
I have been trying to go through this tutorial and I always get stuck in the second build of GCC when making the cross-toolchain. It errors out saying that I am attempting to call a poisoned calloc. I have gone through several patches and what they all seem to do is just #include the offending system header (in this case pthread.h) earlier in the source code. Since there are no patches for my particular problem, I have gone ahead and emulated their solutions in my case. While this works (compilation now fails because I don't have some ISL files) it feels like a hack, and I suspect that the root problem is further back in the build.
Thus, I wanted to ask:
Why are symbols poisoned? Why would the GCC maintainers want some symbols not to be used?
What are the general causes for this problem? Is it really just a bug or is this a problem that arises in more general situations?
I am more interested in the generalities of this issue, but if it helps, I am using the latest release of Alpine Linux (with gcc 12.2.1) trying to compile gcc 11.2
.0 for the same target architecture as the host (x86-64).
I downloaded the latest source code of Opensplice DDS from https://github.com/ADLINK-IST/opensplice and tried to build it by following its instructions (source setenv, source ./configure, then make ..) in my Cygwin 64 bit.
The build (make command) appeared to be completed, but a number of modules such as dcpsisocpp2, durability, spliced didn't get built (I can't find dcpsisocpp2.dll, etc).
I wonder if anyone who is familar with Opensplice's makefile system can direct me to solve the problem.
You should identify you are going to use community or enterprise version.
It seems the community version doesn't have spliced and durability services. Also, dcpsisocpp2 use C++03 which is a very old C++ standard, that when you use C++11 or C++14 writing your application, you might get some warning or error and spend lots of time fixing compile problems.
Try to use dcpssacpp which follows the C++11 standard.
This is the problem:
(On Linux Slackware64) I compiled Inkscape (0.92.3) and found that exporting to PNG doesn't work. An indication on the terminal tells me:
libpng warning: Application built with libpng-1.6.16 but running with 1.5.13
First reaction was to list the linked libraries using ldd. Indeed, both libpng-1.6.16 and libpng-1.5.13 are listed as necessary.
So, I suspected that some of the other libraries was requiring libpng-1.5.13. I made a small Python program which takes all the libraries (except the libpngs) and applies ldd to each of them. None of them listed libpng15. What now? I suspect that if any of the secondary libraries needed libpng15, it would be listed here, but, just in case I made the search recursive. No luck.
So it was, apparently, inkscape itself requesting the old version. A simple search in all files in the search tree only showed the string 'png15' in the viewer and actual inkscape executable.
There are probably older programs of mine still linked with png15, so I probably want to keep that version around.
Most, if not all references on the net mentioning this error (or similar) refer to programs with very old pnglibs (1.2.4x) trying to use a newer version, but here it's the other way around.
libpng-config --version reports 1.6.16
Any suggestion how to identify the source of this problem? Particularly why inkscape included the old libpng?
It seems there were/are efforts to do this, but most of the resources I've seen so far are either outdated (with dead links) or have little to no information to actually build a small working sample (that, for example relies on boost program_options to build an executable).
Also, when using ExternalProject_Add, how does one resolve dependencies inside of Boost?
I'm basically looking to use Boost easily from within CMake with little to no manual configuration.
Try Hunter package manager:
hunter_add_package(Boost COMPONENTS regex system filesystem)
find_package(Boost CONFIG REQUIRED regex system filesystem)
target_link_libraries(foo PUBLIC Boost::regex Boost::system Boost::filesystem)
Note that usage of imported Boost targets is importand for relocatable packages
Wiki
Boost package
Relocation notes
Examples
Small
Big
Currently (August 2017) Boost libraries do not provide CMake support nor are they build using CMake. Boost has its own build system called b2. In July 2017 the Boost steering committee announced that all boost libraries should be moved to use CMake. This affects users and developers, i.e., CMake will be used internally to build the libraries and externally it will provide CMake config files.
As the build system question triggered heated discussions in the past years and there are strong feeling from part of the community against b2 and CMake, the outcome of this decision is unclear (first release with CMake, will all old libraries support CMake, even a split of the Boost community).
Original Answer from 2015
You can consider the effort to introduce CMake as a first-class citizen to boost as dead. See the mailing list thread about the topic.
If you don't want to use third party tools like hunter's package manager, check the most current verion of the boost library you want to use. Maybe you are lucky and it provides some CMakeLists.txt files you can use.
The most recent work on 'a boost which uses CMake and makes boost use ideal for CMake users' is here:
https://github.com/boost-cmake/boost-cmake
It requires cmake master branch (until CMake 3.0.0 is released soon) and I haven't attempted to build it in a while. Someone in the boost community would have to push forward with transitioning boost to CMake. The boost community might still be busy with transitioning to git.
I'm trying to port some very old fortran code to windows. I'd like to use mingw and f2c, which has no problem converting the code to usable C on OS X and Ubuntu. I used f2c.exe as distributed by netlib on a fresh install of mingw, and it translated the code fine. I have a "ported" version of libf2c that seems to still contain some unresolved references -- mostly file i/o routines (do_fio, f_open, s_wsfe, e_wsfe) and, peculiarly, one arithmetic routine (pow_dd). To resolve these issues, I tried to build libf2c from source, but ran into an issue during the make process. The make proceeds to dtime_.c, but then fails due to a dependency on sys/times.h, which is no longer a part of the mingw distro. There appears to be a struct defined in times.h that defines the size of a variable in dtime_.c, specifically t and t0 on lines 53 and 54 (error is "storage size of 't' isn't known"; same for t0).
The makefile was modified to use gcc, and make invoked with no other options passed.
Might anyone know of a workaround for this issue? I feel confident that once I have a properly compiled libf2c, I'll be able to link it with gcc and the code will work like it does on linux and os X.
FOLLOW-UP: I was able to build libf2c.a by commenting out the time related files in the makefile (my code does not contain any time related functions, so don't think it will matter). I copied it to a non-POSIX search directory as show in -print-search-dirs, specifically C:\MinGW\lib\gcc\mingw32\3.4.5. That seems to have fixed the issue on the unresolved references, although the need to eliminate the time files does concern me. While my code is now working, the original question stands -- how to handle makefiles that call for sys/times.h in mingw?
Are you sure the MinGW installation went correct? As far as I can tell the sys/times.h header is still there, in the package mingwrt-3.18-mingw32-dev.tar.gz. I'm not familiar with the gui installer, but perhaps you have to tick a box for the mingwrt dev component.