Glad to hear you’ve made progress - these things can be frustrating to say the least…. I can’t really remember the issues for old gcc versions (it was 5 years or so ago since I last used 4.x gcc) but there are resources listing abi breakages https://gcc.gnu.org/wiki/Cxx11AbiCompatibility as far as I can remember it was just best to recompile all dependencies making sure the compiler flags didn’t ever differ – later gcc’s were better for this but using clang became our preferred solution. Once you’ve gone down the line of rebuilding every dep then you may as well use a newer compiler rather than the one used by the particular linux packager. It does mean you can’t just apt-get X-devel to get X (since that will be built with the wrong compiler and so may or may not work but regardless is a risk) which is a slight pain – but tbh linux packages are always a bit of a hacky solution and don’t fit well with anyone who is building software x-platform (or even X-linux variants)– ie they may make life a bit simpler for a trivial case but generally you need to control how all parts of your solution are built and short cuts like pre-built binaries tend to come back to bite you eventually. A. From: mahmood n [mailto:nt_mahmood@yahoo.com] Sent: 19 October 2017 07:59 To: Alex Perry <Alex.Perry@smartlogic.com> Cc: boost-users@lists.boost.org Subject: RE: [Boost-users] Many undefined references for libboost_filesystem I used another gcc version 4.5 (Ubuntu 11.04) and it works without any problem! I don’t know what is wrong with gcc-4.6. Though the problematic platform was Kubuntuu 12.04. I am know trying with Ubuntu 12.04 which uses gcc-4.6 to see if it is really a gcc problem or the platform! Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Alex Perry<mailto:Alex.Perry@smartlogic.com> Sent: Wednesday, October 18, 2017 4:45 PM To: mahmood n<mailto:nt_mahmood@yahoo.com> Subject: RE: [Boost-users] Many undefined references for libboost_filesystem Actually one other thought (though you may well have solved this by now). Are you sure that the boost libraries you are attempting to link to are using the same abi? Ie how were they built. I only glanced at the github stuff you pointed too but I think I remember that the last commit was 5 years ago or some such – so probably wasn’t using C++11. I note you are using an old (54) version of boost whilst the current is (65) so about 5 years ago as well – but that probably supported being built with c++11.so you might need to rebuild them if they were using a different version of the C++ standard (or any abi breaking change such as 32 vs 64 bit, static runtime vs dynamically loaded etc). Under windows boost normally encodes the abi into the library name and you just automagically (using a msvc extension) link to the appropriate one. That is not the normal way on linux since gcc doesn’t have autolinking so you normally end up sticking them into a separate lib directory and swapping the -L path depending on which abi you want Again though please note this is not boost specific – is just standard C / C++ / Fortran or any obj/link based language issues with building dependencies – (and why most have swapped to using cmake rather than vanilla make to avoid the pain). A. From: Alex Perry Sent: 17 October 2017 16:14 To: 'mahmood n' <nt_mahmood@yahoo.com<mailto:nt_mahmood@yahoo.com>> Subject: RE: [Boost-users] Many undefined references for libboost_filesystem Dropped the rest of the boost list since I’m sure not many are interested!

I didn’t want to have another pain for “finding how the verbose variable is set in the Makefile”!!!

Not hard that one… just add it to the command line when you call make make verbose=1 …..

The libraries do exist, so why on earth it can not link :( mahmood@vb:AES$ g++ -fPIC -L/home/mahmood/boost_1_54_0/stage/lib -lboost_filesystem -lboost_system -m64 -o /home/mahmood/gpgpu-sim_distribution/ispass2009-benchmarks/bin/release/AES obj/x86_64/release/aescuda.cpp.o obj/x86_64/release/aesCudaUtils.cpp.o obj/x86_64/release/aesHost.cu.o -L/usr/local/cuda/lib64 -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../lib -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../common/lib/linux -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../../shared//lib -lcudart -L/usr/local/cuda/lib64 -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../lib -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../common/lib/linux -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../../shared//lib -lcudart -lcutil_x86_64 -lshrutil_x86_64

…. Nope the computer is telling you they don’t exist on those paths as given – unfortunately the computer is more likely to be correct than you on this! You have a lot of library paths being set there – possibly you have multiple versions of boost libraries so its finding the wrong one first so you have a version conflict Possibly the simplest way is create a noddy test and play with the command line till you work out what the problem is http://rextester.com/live/JDVHT54458 That will give you similar compile errors without -lboost_filesystem -lboost_system added to the compile line. Obviously that is using clang rather than gcc which you are using but the syntax and principles are pretty much the same between any c++ compiler HTH A.