-
Notifications
You must be signed in to change notification settings - Fork 215
Troubleshooting
This is a collection of some specific problems and their solutions when working with Hana. These issues lie within the realm of the compilers and are thus not solvable from a library point of view, at least not for now.
Problem: After linking several object files into one executable, the size of the executable is huge, although the compiler seems to have done its job and computed everything at compile-time.
Reason: It appears that Clang has difficulties or fails to remove external symbol names from object files and executables, even when not compiling with debug information. And since the most of the compile-time data is encapsulated in the type system -- as intended and as it is the very purpose of Hana -- these may become huge when working with large amounts of data in compile-time containers like hana::tuple
or hana::map
. Hence, and since those symbols are external, the compiler isn't able to remove them in a single translation unit. The same accounts for strip
. The problem thus lies in the linking process.
Solution: Link your executable with link time optimization enabled (-flto
for Clang and GCC) and invoke strip
afterwards to remove unused symbol names.
References: See #197 for the whole story.
Problem: When compiling with MSVC compatiblility mode enabled Clang-cl and comparing against a regular Clang compiled binary, the sizes of empty structs and of structs inheriting empty structs are increased.
Reason: It's a feature, not a bug, or more of an emulated shortcoming rather than a real bug. MSVC is applying empty base optimization in a rather limited fashion. Only the first inherited empty base class appears to be optimized away, but none of the following. Accordingly, the size increases when inheriting from several empty bases. Unfortunately, Hana makes use of empty base classes for its tag dispatching system. Finally, since Clang-cl emulates MS's cl to be able to parse the MS standard C library and to be binary compatible, it must emulate that shortcoming.
Solution: Sorry, no solution unless you're restricted to use Clang-cl. Consider switching to a regular Clang.
References: See #201 and Stackoverflow