On Fri, 25 Jan 2019 at 08:49, David Aldrich <david.aldrich.ntml@xxxxxxxxx> wrote: > > Hi > > I am using gcc 7.3.0 on Ubuntu 18.04 LTS to build an application that uses > the Boost libraries. I want to use Boost 1.69, which I have installed on > another server. The Ubuntu machine has Boost 1.65 installed. I specify > the remote boost path (to 1.69) in my makefile and 'make' compiles my > source file with: > > > > g++ -c -Wall -m64 -I/net/simdata/OpenSourceLibs/Boost/rel-1.69.0/ -fpic -O3 > SINRCalculation.cpp -o _gnuRelease/SINRCalculation.o > > > > Now, that source file uses boost/multi_array.hpp. The above compiler > command gives error: > > > > In file included from /usr/include/boost/multi_array.hpp:30:0, This was found in /usr/include > from SINRCalculation.cpp:25: > > /net/simdata/Hudson_OpenSourceLibs/Boost/rel-1.69.0/boost/type_traits.hpp:118:10: But this was found in a different path. One that doesn't look the same as the -I path you used (where did the "Hudson_" part come from?) So something is very messed up. Why is the old <boost/multi_array.hpp> being found in the first place? Is that header missing from your boost-1.69 installation? > fatal error: boost/type_traits/is_nothrow_swappable.hpp: No such file or > directory > > #include <boost/type_traits/is_nothrow_swappable.hpp> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > compilation terminated. > > > > Now, my copy of boost 1.69 does contain is_nothrow_swappable.hpp so, at > first sight, that error is surprising. Your copy in /net/simdata/OpenSourceLibs/Boost/rel-1.69.0/ or the one in /net/simdata/Hudson_OpenSourceLibs/Boost/rel-1.69.0/ which is being found? Are they the same? Compile with -save-temps and inspect the SINRCalculation.oii file to see which boost headers are found, in which locations. That should help figure out what's going on. > > > I think what is happening is the is_nothrow_swappable.hpp is being searched > for on the system library path (boost 1.65 does not have that file), not > the one I specified using -I. Seems unlikely, I think something else is happening. > > > > Is this possible? If so, how can I force the compiler to use the boost > 1.69 path consistently for all paths? The -I option you used should already do that, which is why I think you have something messed up with your Boost installations.
