Empty program size on macos

[schveiguy]

On my M1 Mac, building an empty program results in a 5.6MB executable.

void main() {}

results in an executable that is 5617396 bytes in size.

dmd produces a 778976 byte executable from the same program.

using target x86-64 produces a 5.9MB exe.

Is there any way to trim this down? It seems quite absurd for the floor executable size to be almost 6MB.

[kinke]

Thx for the topic; I've quickly experimented on Linux, and came up with #4258. You might be hitting a similar/identical issue, though it seems much worse on Mac here.

[schveiguy]

Thanks for looking at it. Is there a way to try a different linker here? I'm pretty sure ldc2 is using cc to link, but I don't know what is being used there. My only C compiler is what xcode provides.

[kinke]

The C compiler doesn't matter (well, AFAIK, don't know anything about Mac); the -linker flag chooses the linker (forwarding it to the cc invocation), but I'm not sure which linkers are available on Mac / with Xcode (lld only?). - But you could at least try -defaultlib=druntime-ldc and see if that has an impact.

[schveiguy]

Oh yeah! goes down to 1047880 bytes.

[schveiguy]

On mac, it appears that the linker is ld64 which I think is a specialized Apple linker. It probably is based on lld, considering everything they have is based on clang.

[D-a-n-i-l-o]

Take the standard helloworld and compile it (macOS/Linux) using ldc2:

//
// 5.8MB: ldc2 --release --O3 main.d
// 1.2MB: ldc2 --release --O3 -L=-dead_strip -L=-x -L=-S main.d
//
import std.stdio;

void main()
{
    writeln("hello world!");
}

Big executables. (I'm using macOS x64)

Now recompile the D runtime libs using ldc-build-runtime (comes with LDC, it's in the bin directory where ldc2 is):

./ldc-build-runtime BUILD_LTO_LIBS=ON BUILD_SHARED_LIBS=OFF --dFlags="-fvisibility=hidden;-L=-ffunction-sections;-L=-fdata-sections"

Copy the generated libs inside temporary_folder/lib/ into your real ldc/lib folder, overwriting the old ones.

Recompile the helloworld above using the same flags, now you get better results:

// 4.8MB: ldc2 --release --O3 main.d
// 728KB: ldc2 --release --O3 -L=-dead_strip -L=-x -L=-S main.d

Add the -fvisibility=hidden flag and you get:

// 724KB: ldc2 --release --O3 -fvisibility=hidden -L=-dead_strip -L=-x -L=-S main.d

Activating link-time-optimization (LTO) - (time for linking increases!):

// 698KB: ldc2 --release --O3 --flto=full -fvisibility=hidden -defaultlib=phobos2-ldc-lto,druntime-ldc-lto -L=-dead_strip -L=-x -L=-S main.d

With additional -L=-lz:

// 599KB: ldc2 --release --O3 --flto=full -fvisibility=hidden -defaultlib=phobos2-ldc-lto,druntime-ldc-lto -L=-dead_strip -L=-x -L=-S -L=-lz main.d

Same for Linux and other POSIX OS (FreeBSD?, Solaris?), only some linker flags could be slightly different. For example, -L=-S for stripping debug symbols could be lowercase -L=-s on Linux.

The secret is to add the following compiler/linker options when compiling any static libs (like phobos2/druntime):
-fvisibility=hidden -L=-ffunction-sections -L=-fdata-sections

And of course the stripping and dead code removal for final executables.

[kinke]

Current/recent LDC behavior:

Wrt. -fvisibility=hidden for druntime/Phobos: we don't use that for the official prebuilt libs, so that people can still export those statically-linked symbols via -L--export-dynamic from their Posix binary. E.g., this enables resolving symbol names in backtraces (whereas file/line infos require -g debuginfos, so -link-defaultlib-debug).

Wrt. linker GC: -L--gc-sections (ELF) / -L-dead_strip (Apple) / -L/OPT:REF (Windows) is used by LDC by default, unless passing -disable-linker-strip-dead explicitly. LDC also enforces (AFAICT) -function-sections/-data-sections (for its own codegen), unless compiling with -disable-linker-strip-dead. For Windows targets, it emits all symbols in COMDATs, which has an analogous effect.

[kinke]

The secret is to add the following compiler/linker options when compiling any static libs (like phobos2/druntime): -fvisibility=hidden -L=-ffunction-sections -L=-fdata-sections

I'm not aware of linkers supporting -f{function,data}-sections - if Apple ld64 does, I guess it's only used for LTO codegen. Adding them prefixed via -L for ldc-build-runtime's --dFlags makes no difference in any case - they are not used for linking (which happens via the CMake C linker; there are --linkerFlags for this), nor are static druntime/Phobos linked (just the shared libs and test runners).