Re: Per-Object Flags for Autotool C++ library?

[Jeffrey Walton]

On Fri, Nov 3, 2017 at 5:54 AM, Mathieu Lirzin <address@hidden> wrote:
> Hello,
>
> Nick Bowler <address@hidden> writes:
>>
>> On 11/2/17, Jeffrey Walton <address@hidden> wrote:
>>>
>>> CPU_FLAG = -msse2 -msse3 -mssse3
>>> libcpu_a_SOURCES = cpu.cpp
>>> libcpu_a_CXXFLAGS = $(CXXFLAGS) $(CPU_FLAG)
>>
>> Note that you should not include $(CXXFLAGS) here.  CXXFLAGS is always
>> included (so with this it will duplicated on the command line, which
>> might be undesired by the user).
>
> I guess Jeffrey was intending to use AM_CXXFLAGS which is overridden by
> libcpu_a_CXXFLAGS.
>
>>> Now that the objects are built we need to add libcpu.a back into
>>> libcryptopp.la in the exact position it would have been in if I could
>>> have specified per-object flags. The Automake manual gives an example
>>> of linking a program with disjoint libraries, but not adding the
>>> extraneous library back to the main (primary?) library at a particular
>>> position.
>>>
>>> The "in the exact position" is important.
>
> I don't fully understand the "static initialization fiasco", however the
> next entry in the FAQ [1] seems to suggest that it can be avoided
> programmatically using a function wrapper instead of relying on the
> linking order.

Ah, thanks. That relies on Dynamic Initialization and Destruction with
Concurrency (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm).
It is C++11 and only partially available on most platforms. And it is
only available on Windows 10 and above for Microsoft platforms.

We found explicitly controlling the order of initialization produces
the best results on all the platforms we support. There are other
controls that produce even better results, like Linux init_priority
and Microsoft ini_seg, but they are platform specific. We still need
something for AIX, some BSDs, OS X, and Solaris. On AIX, Solaris and
friends we fall back to object file ordering.

> If this kind of issue is common in C++, I think it would be good to
> give a hint in the Automake manual on how to solve it.

With respect to how common it is, in the past I audited open source
C++ projects to get an idea of how widespread the problem could be.
Something like 80% of them had objects that could suffer the problem
(emphasis "could").

The fix is rather easy once you know the cause. Once the dependencies
have been determined among translation units, you just order the
object files accordingly. A well written program or library will have
few (or none) of them. In our case, we have 160 source files, 1400
classes, and only 3 object files matter. The rest of the object files
are "don't care", and we order them alphabetically for a deterministic
build.

Some of the of the things Automake could do to help with the problem
are (1) honor existing list orders (certainly do not reorder them),
and (2) make it easy to combine sublibraries (?) into the primary
library due to per-object flags. And maybe (3) is, add better support
for per-object flags so sublibraries do not need to be combined in the
first place.

For documentation updates, I would like to see an example of how to
combine libraries when sublibraries must be combined due to per-object
flags. I recommend it be places on the Per-Object Flags page where the
example for a program is:
https://www.gnu.org/software/automake/manual/html_node/Per_002dObject-Flags.html
.

I kind of like the idea of (3) because we have a lot of source files
that require architectural specific flags:
https://github.com/weidai11/cryptopp/blob/master/GNUmakefile#L983 . As
we add more ARM NEON and Aarch32/64 support the list is going to get
bigger. It would be nice if we did not need to build a separate
library for them.

Jeff