limbo018 / OpenMPL

An open multiple patterning framework
BSD 3-Clause "New" or "Revised" License
67 stars 41 forks source link

undefined reference to `boost::timer' libraries while building #15

Open MolyOre opened 1 year ago

MolyOre commented 1 year ago

I am trying to build OpenMPL project. However some errors happens with the boost library

[ 99%] Linking CXX executable OpenMPL CMakeFiles/OpenMPL.dir/main.cpp.o: In functionmain': main.cpp:(.text.startup+0xc4): undefined reference to boost::timer::auto_cpu_timer::auto_cpu_timer(std::string const&)' libOpenMPL_lib.a(SimpleMPL.cpp.o): In functionSimpleMPL::SimpleMPL::read_gds()': SimpleMPL.cpp:(.text+0x337): undefined reference to boost::timer::auto_cpu_timer::auto_cpu_timer(std::string const&)' libOpenMPL_lib.a(SimpleMPL.cpp.o): In functionSimpleMPL::SimpleMPL::write_gds()': SimpleMPL.cpp:(.text+0x1364): undefined reference to boost::timer::auto_cpu_timer::auto_cpu_timer(std::string const&)' libOpenMPL_lib.a(SimpleMPL.cpp.o): In functionSimpleMPL::SimpleMPL::solve()': SimpleMPL.cpp:(.text+0xa59e): undefined reference to boost::timer::format(boost::timer::cpu_times const&, short, std::string const&)' SimpleMPL.cpp:(.text+0xa633): undefined reference toboost::timer::format(boost::timer::cpu_times const&, short, std::string const&)' SimpleMPL.cpp:(.text+0xa7dc): undefined reference to boost::timer::format(boost::timer::cpu_times const&, short, std::string const&)' SimpleMPL.cpp:(.text+0xa968): undefined reference toboost::timer::format(boost::timer::cpu_times const&, short, std::string const&)' SimpleMPL.cpp:(.text+0xaa03): undefined reference to boost::timer::format(boost::timer::cpu_times const&, short, std::string const&)' libOpenMPL_lib.a(SimpleMPL.cpp.o):SimpleMPL.cpp:(.text+0xaaa6): more undefined references toboost::timer::format(boost::timer::cpu_times const&, short, std::string const&)' follow collect2: error: ld returned 1 exit status `

How can I fix the problem?

I have tried to change the boost version from 1.55 to 1.72 and try to install boost in other ways. I have also tried to change the installation path. But these still cannot work.

wadmes commented 1 year ago

Hi thanks for the report, we may suggest you trying the docker version:

docker pull wadmes/openmpl:latest
amosteernamazz commented 10 months ago

i met the same problem

Chilkings commented 6 months ago

same problem, I tried boost1.69 and 1.71, but it didn't work

limbo018 commented 6 months ago

Hi, I replaced boost::timer with the timer in stl in the develop branch (https://github.com/limbo018/OpenMPL/commit/56caaa94b0ef5c3f945191d9ebd964098859c65d). Can you pull and try again?

Chilkings commented 6 months ago

Hi, I replaced boost::timer with the timer in stl in the develop branch (56caaa9). Can you pull and try again?

Thank you very much for your fix, it works. But there is still a problem when I try to enable gurobi. I modified the following statement in CMakeLists.txt to try to enable Gurobi support.

option(ENABLE_GUROBI "whether enable Gurobi" ON)
message("-- GUROBI: ${ENABLE_GUROBI}")
set(GUROBI_LIBRARY /opt/gurobi1100/linux64/lib/libgurobi110_light.so)
include_directories("/opt/gurobi1100/linux64/include")

The compilation error message is as follows:

[ 99%] Built target gdsdb
[ 99%] Built target defwrite
Consolidate compiler generated dependencies of target OpenMPL
[ 99%] Linking CXX executable bin/defrw
[ 99%] Linking CXX executable OpenMPL
[ 99%] Built target defdiff
[ 99%] Built target defrw
/usr/bin/ld: [ 99%] Linking CXX static library liblefparser.a
[ 99%] Built target lefparser
libOpenMPL_lib.a(SimpleMPL.cpp.o): in function `limbo::algorithms::coloring::LPColoring<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_index_t, unsigned int, boost::no_property>, boost::property<boost::edge_index_t, unsigned int, boost::property<boost::edge_weight_t, float, boost::no_property> >, boost::no_property, boost::listS> >::solve_model(GRBModel&)':
/home/gc666/Desktop/OpenMPL/thirdparty/Limbo/limbo/algorithms/coloring/LPColoring.h:559: undefined reference to `GRBModel::write(std::string const&)'
/usr/bin/ld: /home/gc666/Desktop/OpenMPL/thirdparty/Limbo/limbo/algorithms/coloring/LPColoring.h:567: undefined reference to `GRBModel::write(std::string const&)'
/usr/bin/ld: /home/gc666/Desktop/OpenMPL/thirdparty/Limbo/limbo/algorithms/coloring/LPColoring.h:571: undefined reference to `GRBModel::write(std::string const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/OpenMPL.dir/build.make:109: src/OpenMPL] Error 1
make[1]: *** [CMakeFiles/Makefile2:2087: src/CMakeFiles/OpenMPL.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

I'm using boost 1.71 and gurobi 11.0.0 under Ubuntu 22.04.

limbo018 commented 6 months ago

It looks like your gurobi version is quite new. I just modified cmake/FindGurobi.cmake to find latest gurobi versions (see https://github.com/limbo018/OpenMPL/commit/07f5f5a7e600b80e23492833b32450a1ec960f6b). I don't think you need to manually set GUROBI_LIBRARY or include gurobi directories in CMakeLists.txt. What you need to do is to export GUROBI_HOME as environment variable before running cmake:

export GUROBI_HOME=/opt/gurobi1100/linux64
Chilkings commented 6 months ago

It looks like your gurobi version is quite new. I just modified cmake/FindGurobi.cmake to find latest gurobi versions (see 07f5f5a). I don't think you need to manually set GUROBI_LIBRARY or include gurobi directories in CMakeLists.txt. What you need to do is to export GUROBI_HOME as environment variable before running cmake:

export GUROBI_HOME=/opt/gurobi1100/linux64

Thank you very much, I have solved this problem. I have already added GUROBI_HOME to .bashrc file before. It should be a gurobi version problem. But in [07f5f5a]https://github.com/limbo018/OpenMPL/commit/07f5f5a7e600b80e23492833b32450a1ec960f6b) seems doesn't work. I manually added the following statements to the FindGurobi.cmake file in line 37 and the compilation was successful.

set(GUROBI_LIBRARY /opt/gurobi1100/linux64/lib/libgurobi110.so)
MolyOre commented 6 months ago

I have solved the problem in the master branch. Just simply change the ABI marco from 0 to 1 in the top CMakeLists.txt can fix the bug. It seems that the bug is caused by the conflict between C98 and C11 standard for the "timer" lib.

if(NOT CMAKE_CXX_ABI) set(CMAKE_CXX_ABI 0 CACHE STRING // change the 0 to 1 "Choose the value for _GLIBCXX_USE_CXX11_ABI, options are: 0|1." FORCE) endif(NOT CMAKE_CXX_ABI)