Bruno Haible <[email protected]> writes:

> Hi Collin,
>
> Thanks for investigating.

No problem.

>> #  if __GLIBC__ >= 2 && defined __USE_EXTERN_INLINES
>
> __USE_EXTERN_INLINES depends on the optimization level. It is not uncommon,
> when building a package, that different object files are compiled with
> different optimization levels. This could thus lead to an undefined symbol
> at link time.

I see. I figured most people used the same optimization level for an
entire package. But I guess there might be a reason to disable
optimizations for a single file single file.

>> It works with my machine with 'clang -O3 -fsanitize=address',
>> so I assume optimizations are disabled once '-fsanitize' is used.
>
> That looks weird and strange.
>
> I would better avoid this fragile route. How about skipping this part
> of the test if ASAN is enabled? This can be done through this idiom,
> already used in a couple of test files:
>
> #ifndef __has_feature
> # define __has_feature(a) 0
> #endif
> #if defined __SANITIZE_ADDRESS__ || __has_feature (address_sanitizer)

Yep, that seems more robust.

I wonder if it is worth adding the checks for __has_feature,
__has_include, etc. in m4/gnulib-common.m4 so that we don't need to
repeat the #ifdef's around everywhere, we can just assume it is defined
in config.h. Any reason to avoid that?

Collin

Reply via email to