boost.m4 icon indicating copy to clipboard operation
boost.m4 copied to clipboard

Macros always add -R/usr/local/lib regardless of boost location

Open kalleh opened this issue 14 years ago • 8 comments

I have the following calls in in my configure.ac:

BOOST_REQUIRE BOOST_BIND BOOST_ASIO BOOST_ARRAY BOOST_SYSTEM BOOST_THREADS BOOST_SMART_PTR

And this results in -R/usr/local/lib being added to my compiler options even though my boost headers and libraries resides in /usr not /usr/local.

kalleh avatar Jan 14 '10 15:01 kalleh

Can you please send me your entire config.log? (since github's issue tracking system doesn't support adding attachments to an issue, please send it directly to me by email.)

tsuna avatar Jan 14 '10 16:01 tsuna

I've sent it by email!

kalleh avatar Jan 14 '10 16:01 kalleh

Are you sure that you don't have boost in /usr/local?

configure:15292: g++ -o conftest -g -O2    -L/usr/lib conftest.o -lboost_system-d-1_38  >&5
/usr/bin/ld: cannot find -lboost_system-d-1_38
collect2: ld returned 1 exit status
configure:15301: $? = 1
[...]
configure:15286: re-using the existing conftest.o
configure:15292: g++ -o conftest -g -O2    -L/usr/local/lib conftest.o -lboost_system-mt  >&5
configure:15301: $? = 0
configure:15340: result: yes

With -L/usr/lib it didn't link but it worked with -L/usr/local/lib...

tsuna avatar Jan 17 '10 08:01 tsuna

No sorry, I also tried distclean etc if the setting were cached somehow with no success. Please note that the app still compiles, mainly (?) because g++ does not support the -R during compilation (it's only a linker flag).

kalle@ubuntu:/usr/local/lib$ pwd /usr/local/lib kalle@ubuntu:/usr/local/lib$ ls python2.6 site_ruby

kalleh avatar Jan 18 '10 08:01 kalleh

I don't know if this can trigger this bug, but I only have the -mt version of the boost libraries installed. boost.m4 works perfectly though and identifies this case, but the only issue is the extra -R/-L flags which is not necessary.

kalleh avatar Jan 18 '10 08:01 kalleh

OK, I think I understand the bug. boost.m4 is trying various combinations of -L flags and -l flags to guess the one that works. The problem in your case is that it manages to find the right -l with the wrong -L because GCC ignores the "bogus" -L because the library specified with the -l can be found in GCC's default search path. I don't have time to fix this right now but I'll take a look in a few days when I have some free time in my hands.

tsuna avatar Jan 20 '10 05:01 tsuna

No worries there is no hurry, as I said the build works, this bug just creates unnecessary warnings in the output. And thanks for your time helping me debug this problem!

kalleh avatar Jan 20 '10 08:01 kalleh

You can also avoid the -R/usr/local issue completely by setting the -R to $ORIGIN:

-R$ORIGIN

where $ORIGIN is a special linker keyword, not a shell variable, and it will cause all Boost libraries depending on eachother to search in their own directory ($ORIGIN) first. $ORIGIN is supported by GNU, SunOS (Solaris / illumos), and HP-UX ld.

UX-admin avatar Sep 06 '15 13:09 UX-admin