Messing around with linkers & CMake

[Adriaan de Groot]

In some cases, we end up with shared-libs that are too big to include debug 
info; webkit2, webengine come to mind. Here's one way to mess with the linking 
step (bear in mind, I haven't played at *all* with the consequences this has 
nor how variable-scope affects generation).

Consider

	add_library(foo SHARED foo.c)

Build this in verbose mode:
	cmake .
	make foo VERBOSE=1
See how the compiler is invoked at the end to link the library?


Now consider this:

	set(CMAKE_C_CREATE_SHARED_LIBRARY
		"<CMAKE_LINKER> <CMAKE_SHARED_LIBRARY_C_FLAGS> 
<LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS> 
<SONAME_FLAG><TARGET_SONAME> -o <TARGET> <OBJECTS> <LINK_LIBRARIES>")
	add_library(foo SHARED foo.c)

This messes with the command that CMake uses -- and later expands -- to create 
shared libraries from C code; the standard definition is in 
./Modules/CMakeCInformation.cmake , and uses <CMAKE_C_COMPILER> while setting 
the variable ourselves lets us choose the linker instead. Note that this 
*won't* compile, since the flags for the linker are seriously different from 
what the C compiler expects (in particular, you'll see -Wl,-soname in there 
where the linker invoked directly wants -soname).


Probably by massaging this variable in a suitable manner you can stuff in any 
particular tool you want.

[ade]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20170309/ce4dfa54/attachment.sig>