NFD

We are already adding (should have been active) these flags whenever BOOST is specified in 'use'. Can you specify where exactly you see the problem?

The problem is that the pthreads test does not detect that "-pthread" is required, causing the Boost test to fail to compile with a linker error due to missing pthread DSO. This is what appears on the console:

Checking boost includes                              : 1.61.0 
Checking boost libs                                  : ok 
Checking the flags needed to use pthreads            :  
Checking for boost linkage                           : Could not link against boost libraries using supplied options

This is the relevant part of build/config.log:

err: /usr/bin/ld: test.cpp.1.o: undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

Alex, please take a look at the linked gcc bug report.

Basically what happens is that when you build with -fsanitize=address, the ASan library libasan is automatically added to the linker command line. That library provides some (but not all) pthreads symbols, and those one are apparently enough to satisfy all the undefined references that the linker finds when linking the PTHREAD_CODE test program in boost.py. Therefore the configure thinks that no flags are needed to enable pthreads on the platform. However, when linking the boost test program, some additional pthreads symbols are needed, and those are not provided by libasan, so linking fails this time.

This issue can be fixed by adding "-pthread" to the CXXFLAGS and LINKFLAGS in .waf-tools/sanitizers.py.

This is just a quick workaround (properly implementing it would require duplicating the detection logic for the exact pthreads flag to be used on the platform). A cleaner solution would be adding the -fsanitize=* flags only when actually building our code, not during the (rest of the) configure process.

A cleaner solution would be adding the -fsanitize=* flags only when actually building our code, not during the (rest of the) configure process.

This can be achieved by moving the sanitizer waf-tool last.

This can be achieved by moving the sanitizer waf-tool last.

There is also an alternative approach by defining sanitize_CXXFLAGS and sanitize_LINKFLAGS variables and adding sanitize as a use dependency to the build targets. Although, this potentially has a danger of missing some code from being sanitized.

I am more inclined to proceed with Junxiao's suggestion and simply load the sanitizers tool as a last thing during the configuration stage. Davide, what would be your preferred solution?

I don't have any strong preference towards one or the other.

I also think Junxiao's solution is more straightforward. If we're all in agreement about it, I'll update the issue description.

It seems that I don't have the correct permissions to update the issue description. Could someone change it to match Junxiao's suggestion in note 4?

Eric Newberry wrote:

This issue does not affect ndn-tools.

For consistency reasons, I would apply the same change to ndn-tools as well.