tsuna
BOOST_LDPATH not set on 64bits Debian multiarch
Greetings,
I am reporting that boost.m4 does not seem to fill-in the following variables when run on a Debian GNU/Linux box:
BOOST_CHRONO_LDFLAGS = BOOST_CHRONO_LDPATH = BOOST_CHRONO_LIBS = -lboost_chrono BOOST_CPPFLAGS = -pthread BOOST_DATE_TIME_LDFLAGS = BOOST_DATE_TIME_LDPATH = BOOST_DATE_TIME_LIBS = -lboost_date_time BOOST_FILESYSTEM_LDFLAGS = BOOST_FILESYSTEM_LDPATH = BOOST_FILESYSTEM_LIBS = -lboost_filesystem BOOST_IOSTREAMS_LDFLAGS = BOOST_IOSTREAMS_LDPATH = BOOST_IOSTREAMS_LIBS = -lboost_iostreams BOOST_LDPATH = BOOST_LIBS_DIR = BOOST_PROGRAM_OPTIONS_LDFLAGS = BOOST_PROGRAM_OPTIONS_LDPATH = BOOST_PROGRAM_OPTIONS_LIBS = -lboost_program_options BOOST_REGEX_LDFLAGS = BOOST_REGEX_LDPATH = BOOST_REGEX_LIBS = -lboost_regex BOOST_ROOT = BOOST_SERIALIZATION_LDFLAGS = BOOST_SERIALIZATION_LDPATH = BOOST_SERIALIZATION_LIBS = -lboost_serialization BOOST_SYSTEM_LDFLAGS = BOOST_SYSTEM_LDPATH = BOOST_SYSTEM_LIBS = -lboost_system BOOST_THREAD_LDFLAGS = BOOST_THREAD_LDPATH = BOOST_THREAD_LIBS = -lboost_thread -lboost_system -pthread
What the test shows is that when trying to find header files, everything is ok.
BUT, each time the test tries to locate the library, it fails. I guess this is
because in my Debian box, the headers are in /usr/include, while the libs are
in /usr/lib/x86_64-linux-gnu, which is not tested, apparently, as a potential
location for libs. However the -l
gcc -print-multiarch provides just this: x86_64-linux-gnu, so I wonder if, to make the macros compatible with Debian and Ubuntu (they have not adopted the standard that RedHat has), we should not try to get that potential lib path using it dynamically.
Are my assumptions correct? If so can we expect a fix? I really have little knowledge in autotools, otherwise I would try to make a patch. Sorry. Sincerely, Filippo Rusconi [email protected]
