On Fri, Nov 3, 2017 at 5:54 AM, Mathieu Lirzin <m...@gnu.org> wrote: > Hello, > > Nick Bowler <nbow...@draconx.ca> writes: >> >> On 11/2/17, Jeffrey Walton <noloa...@gmail.com> 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
