zig cc: unsupported linker arg: -Map=skrouterd.map

[jiridanek]

Zig Version

0.11.0

Steps to Reproduce and Observed Behavior

Here's a fragment of my actual command (obtained from VERBOSE=1 make)

$ clang -O2 -g -DNDEBUG -flto=thin -Wl,--export-dynamic -rdynamic  -Xlinker -Map=skrouterd.map
/usr/bin/ld: /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../lib64/crt1.o: in function `_start':
(.text+0x1b): undefined reference to `main'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Clang does not complain about the -Map option (and if all parameters were given, the linking would succeed)

When I run the same compilation with zig cc instead of clang, I get an error from command line argument parser

$ zig cc -O2 -g -DNDEBUG -flto=thin -Wl,--export-dynamic -rdynamic  -Xlinker -Map=skrouterd.map
error: unsupported linker arg: -Map=skrouterd.map

Expected Behavior

Please support the -Map= linker argument. I can try looking into this myself if given some initial pointers on what needs to be done. Thanks.

[jiridanek]

Looks like the first step towards implementing this would be here

zig/src/main.zig

Lines 2397 to 2402 in 1b0e913

	} else if (mem.eql(u8, arg, "--version")) {
	try std.io.getStdOut().writeAll("zig ld " ++ build_options.version ++ "\n");
	process.exit(0);
	} else {
	fatal("unsupported linker arg: {s}", .{arg});
	}

Looking at the previous issues of this kind, it looks to me that fix should be similar to how wrap is handled

• Support "--version" linker argument #16154
• add linker -wrap flag #15097

[andrewrk]

I'm marking this as a proposal to indicate that we might not decide to support it after all. Diagnostic and debugging features are important, but it is an area we may choose to diverge from other tools in order to unlock a different set of design requirements.

I think it would be better to decide what to do about this feature request until after #17749 is done.

[jiridanek]

After having a second look at the project I wanted to cross-compile, I realized that indeed the linker map is written out only for human inspection and the software itself does not touch it afterwards. It does not even try to install the map file to /usr/share or something like that... Previously I somehow got stuck on the idea that it loads the map file at runtime and parses out something out of it, which simply is not the case. (It does open and read /proc/self/map, but that is something completely different.)

So, I used cmake to check for -Map availability and skip it if not supported. Problem solved.

include(CheckLinkerFlag)
check_linker_flag(C "LINKER:-Map=skrouterd.map" linker_map_supported)

add_executable(skrouterd ${router_SOURCES})
target_include_directories(skrouterd PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
target_link_libraries(skrouterd PRIVATE skupper-router)
if (linker_map_supported)
    target_link_options(skrouterd PUBLIC LINKER:-Map=skrouterd.map)
else ()
    message(WARNING "Linker map generation not supported, skrouterd.map will not be written out")
endif ()

[andrewrk]

Nice work finding a workaround - thanks for sharing it here.