I have compiled a C++ program that need libboost-system1.46. I'm using Ubuntu 14.04 so I have libboost-system1.54. When I run the program it says that libboost_filesystem.so.1.46.1 was not found. How can I (if it is possible) to make the program work with libboost-system1.54. Perhaps there's a place where we specify which version to use. Is what I thinking is correct?
You need to recompile against the newer version of library. AFAIK boost libraries are not binary compatible between versions, so simple . You could do tricks, to use the other version (symbolic links or other magic), but it would most probably not work.
So you either need to provide the version that is required or change the requirement - recompilation.
If you wrote the program, or built it, you just need to repeat the whole build procedure, with all the configures before the make or compilation. Technically, just relinking should work, but some systems like CMake cache the configuration options evaluated at this step, and simply, calling make again would not work. So I would suggest to repeat whole process.
Whatever the procedure looked, it should suffice just to repeat it.
You may be able to create a symbolic link which points the name libboost-system1.46 to libboost-system1.54.
This will work as long as the interfaces for the functionality you're using hasn't changed, though is probably not a good idea. It may work just get your code going and tested, but would never be appropriate for any sort of release software.
You should try to recompile your program with the newer version of boost.
Related
I am trying to compile vhdl code using ghdl compiler. However I am missing two util libraries:
util.misc_conv_pkg and
util.vstring.
therefore this code is not working
LIBRARY util;
USE util.misc_conv_pkg.ALL;
USE util.vstring.ALL;
I have tried all possible installations methods I found:
http://ghdl.free.fr/site/pmwiki.php?n=Main.Installation
or
https://sourceforge.net/p/ghdl-updates/wiki/Installing%20ghdl/
But it is still not working. How do i fix this.
You need to find the source for those packages and compile them into the util library. They are part of the project you're working on, not part of VHDL.
If you can't find them, just comment out the USE clauses. Then one of two things will happen...
They aren't actually used at all, in which case the project will compile and work fine without them, and you have cleaned it up by eliminating unnecessary dependencies. It's amazing how often this is the case with those deprecated std_logic_arith packages.
Some functions or declarations from them are used, in which case compilation will fail with a fairly accurate description of what's missing. (Add the first few to the question if necessary).
Normally with a "util" library, the functionality is fairly obvious, so you can either find a more standard or more portable way of doing it, or you can write your own package that fulfils JUST the bits required for this project.
I want to conditionally compile some c++ code that uses boost, and make it so it doesn't try to compile the boost dependent code if boost is not present.
Does boost have any global macro that will be defined, like __BOOST__, that I can check for?
EDIT: It's clear to me now that I have to achieve this on the makefile level. I am working on OSX lion. Using gnu make
The TYPICAL way that this is done is to use a "configuration script" or similar, that detects if the required/optional component(s) is/are present, and then selectively sets some -D options to the build system.
Obviously, if it's just your own project or a small distribution, you could do the same thing manually.
You probably also need a couple of ifdef type of choices in the Makefile if there are library files that you need.
One of the easier ways to determine if a part of boost that you need is installed is to try to compile it. If there are errors, the likely cause is that that part of boost isn't present (this obviously doesn't work if there are more important parts missing - for example, not having a compiler or standard library installed will ALSO cause a compile to fail. This is why nearly all configure type tools "start with the most basic features, and work their way up the tree of dependencies").
I have compiled my preload file on Ubuntu server (two files for x32 and x64). Where I can get list, in which I will see with what OS my compiled files are compatible and with what I should recompile for compatibility?
Thanks!
Use Linux App Checker developed by ISPRAS and The Linux Foundation. It's designed to perform cross-distro compatibility checks for Linux applications. See sample reports here.
I would start by attempting to execute the program on various Linux distributions in a virtual machine. Pick the top three most popular Linux distributions or the ones your users are most likely to have.
Also, you may be better off to distribute a statically linked binary and offer the source code to others who wish to build it themselves (if you are allowed to distribute source).
I don't know if I fully understand you, but, if my understanding is not that wrong, I'd start by ldd -v. Any OS that is architecture compatible and has the dependent libraries installed in compatible versions should work.
Next, if you plan to support more architectures, you need explicitly to know it and cross compile for every one of it.
So, you must recompile for:
1. Every different architecture.
2. When library versions are not compatible.
This last one is more tricky, since your code may need specific versions to work, but you must know it anyway from start.
Please tell me if it is not what you wanted.
I would like to start using boost in an embedded environment. I can live without boost libraries that require compilation for quite sometime. I suppose just moving boost directory into appropriate place in our code base will do the trick
Am I right about it or it is more involved than that?
How to get rid of header files for the libraries that are not being used?
Are there any gcc version dependencies in boost libraries. E.g. can use gcc-4.1.1 with the latest?
Am I right about it or it is more involved than that?
That will do it.
How to get rid of header files for the libraries that are not being used?
Why bother? They're not going to be compiled into the program. When you deploy your distribution won't be any different whether you remove them or not.
Are there any gcc version dependencies in boost libraries. E.g. can use gcc-4.1.1 with the latest?
vOv - That's a very old version. Boost takes things a lot further than most, more that I think they should most of the time, trying to make sure it works with old and/or broken compilers. You're really pushing it though.
I have not tried it myself, but if you compile Boost with a directory prefix, then I suppose you could move the directory later. I can't see a big problem with that or at least one that can't be fixed quickly.
As for getting rid of header files for libraries that aren't use, look into the bcp utility for the version with which you are using:
http://www.boost.org/doc/libs/1_49_0/tools/bcp/doc/html/index.html
It is "a tool for extracting subsets of Boost" -- exactly what you are looking for.
As for your last question, I think it depends on what version of Boost you are using. I've never had a problem with gcc dependencies...it seems their requirements are fairly liberal. I don't think you need to be worried too much about it unless you plan to use a version of gcc that is "much" older (than the Boost you plan to use). I would guess 'old' here is old enough that you don't need to worry -- any number that I would say would be merely a guess...
Hope this helps!
I've got a C++ project where we have loads and loads of dependencies. The project should work on Linux and Windows, so we've ported it to CMake. Most dependencies are now included right into the source tree and build alongside the project, so there are no problems with those.
However, we have one binary which depends on Fortran code etc. and is really complicated to build. For Linux, it's also not available as a package, but only as precompiled binaries or with full source (needs a BLAS library installed and several other dependencies). For windows, the same library is available as binary, building for Windows seems even more complicated.
The question is, how do you handle such dependencies? Just check in the binaries for the supported platforms, and require the user to set up his build environment otherwise (that is, manually point to the binary location), or would you really try to get them compiled along (even if it requires installing like 10 libraries -- BLAS libraries are the biggest pain here), or is there some other recommended way to handle that?
If the binary is independant of the other part of your build process, you definitively should check-in it. But as you cannot include every version of the binary (I mean for every platform and compile flags the user might use) the build from source seems mandatory.
I have done something similar. I have checked-in the source code archives of the libraries/binaries I needed. Then I wrote makefile/scripts to build them according to the targeted platform/flags in a specific location (no standard OS location) and make my main build process to point to the right location. I have done that to be able to handle the correct versions and options of the libraries/binaries I needed. It's quite a hard work to make things works for different platforms but it's worth the time !
Oh, and of course it's easier if you use crossplatform build tools :)
One question to you. Does the users need to modify this binary, or are they just happy it's there so the can use/access it? If they don't need to modify it, check in the binaries.
I would agree, check in the binaries for each platform if they are not going to be modified very often. Not only will this reduce build times, but it will also reduce frustration from unnecessary compilations.