BOOST_LDPATH not set on 64bits Debian multiarch

[lopippo]

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 switch is created fine because my understanding is that the macro tries a link, and the system itself obviously knows where to find the libs (namely in /usr/lib/x86_64-linux-gnu).

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]