Hi Joseph,
>> I noticed we have duplicate .m4 code that detects information about linker
>> in lib* folders:
>>
>> libffi/acinclude.m4 - this one is merge from the upstream project
>>
>> libatomic/acinclude.m4
>> libgomp/acinclude.m4
>> libitm/acinclude.m4
>> libstdc++-v3/acinclude.m4
>>
>> I prepared a proof-of-concept patch that factors out the code for libgomp and
>> libatomic.
>> Is it something we want to? If so, I can try finished that for next stage1.
>
> I support the principle of refactoring this code, as I said in
> <https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00883.html> (Rainer
> said in <https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00885.html>
> that he was working on it).
I had started on removing lots of duplication in the target lib
acinclude.m4's, resulting in a series of patches:
[build] Split off linker version check from *_CHECK_LINKER_FEATURES
[build] Unify LIB*_CHECK_LINKER_FEATURES macros
[build] Unify LIB*_ENABLE_SYMVERS macros
and many more that I'd found but not even started working on, like
*_CHECK_ATTRIBUTE_ALIAS, *_CHECK_ATTRIBUTE_DLLEXPORT,
*_CHECK_ATTRIBUTE_VISIBILITY, *_CHECK_SYNC_BUILTINS, various *_ENABLE
macros, handling of --enable-version-specific-runtime-libs and
--enable-generated-files-in-srcdir. Many of those were quite entangled.
Unfortunately, I both got distracted and the code proved to be an
incredible mess with lots of changes and additions to equivalent macros
in only a (sometimes small) subset of the duplicate copies. Any change
in this area will require extensive testing if one wants to avoid
massive breakage on a large number of platforms, especially non-Linux
ones.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
