Problems integrating MetaMaps with Boost

[ArnieBerg]

There is a problem with where MetaMaps expects the Boost components to be. If Boost is installed according to the steps given in https://www.boost.org/doc/libs/1_72_0/more/getting_started/unix-variants.html (and don’t forget step 5.1, Easy Build and Install), the resulting folder structure is different from what MetaMaps expects.

Suppose Boost is installed in /usr/local/boost_1_72_0. The include folder appears in /usr/local/boost_1_72_0/boost/include, but MetaMaps expects it in /usr/local/boost_1_72_0/include. If the include folder is copied to where MetaMaps expects it, this resolves that issue.

However, MetaMaps expects the lib folder to appear in /usr/local/boost_1_72_0, but it appears in /usr/local/boost_1_72_0/stage. After the lib folder is copied to where MetaMaps expects it, then ‘make metamaps’ finds it. However, when you now try to run MetaMaps, the following error occurs:

./metamaps: error while loading shared libraries: libboost_filesystem.so.1.72.0: cannot open shared object file: No such file or directory

The libboost files are in the /usr/local/boost_1_72_0/lib folder, but MetaMaps does not find it there. Is there a way to install and run MetaMaps to avoid these contortions? Where does MetaMaps expect to find the libboost files?

[ArnieBerg]

This seems to be a common issue. Can we have some attention to this? We are ready to abandon MetaMaps due to slow response.

[AlexanderDilthey]

Sorry for slow response, @ArnieBerg. The last problem - MetaMaps not finding libboost_filesystem.so.1.72.0 - will be solved by including the directory that contains the Boost library files into the environment variable LD_LIBRARY_PATH.

[cjain7]

While I and Alex are looking into this.. I've following comment for troubleshooting this problem at your end:

Boost install directory and source directory are different Metamaps needs the boost install directory which can be different from where boost source code is. In the boost link you shared above, the documentation says that you can explicitly control the boost install directory using --prefix option (see section 5.1 of that article). If --prefix option is not provided, it will use a default folder.

Metamaps understands boost file system

The link you shared also says the following: The install command will leave Boost binaries in the lib/ subdirectory of your installation prefix. You will also find a copy of the Boost headers in the include/ subdirectory of the installation prefix, so you can henceforth use that directory as an #include path in place of the Boost root directory.

My suggestion for you is make a new folder, and provide that folder's absolute path to prefix option. Do a re-install of boost, and let that folder be your boost build directory. Then you can provide that folder's absolute path to Metamaps as well.

BTW, if you think there is a bug in Metamaps, you are welcome to tweak Metamaps boost configuration here, but i'm not sure if that will help. Usually, the file hierarchy is a standard thing, it shouldn't change.

Let us know if the above tips help.. if not we will try using boost 1.72.0 at our end.

[ArnieBerg]

Thank-you! This was the answer I was looking for.

Solution: Issue export LD_LIBRARY_PATH=/usr/local/boost_1_72_0/lib:${LD_LIBRARY_PATH} command.