= phenomenon =
dmtcp is under review: https://bugzilla.redhat.com/show_bug.cgi?id=750394
One of its binaries is statically link as follows:
{{{ gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer- size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -O0 -g -DDMTCP_VERSION=\"1.2.4\ " -fno-stack-protector -static -nodefaultlibs \ -o mtcp_restart mtcp_restart.c mtcp_maybebpt.o \ mtcp_printf.o mtcp_util.o mtcp_safemmap.o \ mtcp_state.o mtcp_safe_open.o mtcp_check_vdso.o mtcp_fastckpt.o }}}
Does this need an exception ALA https://fedoraproject.org/wiki/PackagingGuidelines#Statically_Linking_Executables ?
= background analysis =
Upstream comment:
mtcp_restart plays tricks with memory maps and earlier ASLR/VDSO/heap used to come in the way and the solution was to make it static.
I'm not sure that this case even needs an exception (the clause is primarily aimed against linking in libraries statically), but given how special this program is, I think allowing it makes perfect sense.
Note that this doesn't link to libc.a at all, only to the crt{1,i,beginT,end,n}.o modules. This is the link command:
{{{ COLLECT_GCC_OPTIONS='-v' '-v' '-O2' '-g' '-pipe' '-Wall' '-fexceptions' '--param' 'ssp-buffer-size=4' '-fasynchronous-unwind-tables' '-O0' '-g' '-D' 'DMTCP_VERSION=1.2.4' '-fno-stack-protector' '-static' '-nodefaultlibs' '-o' 'mtcp_restart' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.6.2/collect2 --build-id --no-add-needed -m elf_x86_64 --hash-style=gnu -static -o mtcp_restart /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.6.2/crtbeginT.o -L/usr/lib/gcc/x86_64-redhat-linux/4.6.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../.. /tmp/cctO8hqW.o mtcp_maybebpt.o mtcp_printf.o mtcp_util.o mtcp_safemmap.o mtcp_state.o mtcp_safe_open.o mtcp_check_vdso.o mtcp_fastckpt.o /usr/lib/gcc/x86_64-redhat-linux/4.6.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/crtn.o }}}
and below is the list of non-"mtcp_" symbols in the binary.
{{{ 0000000000405620 R _IO_stdin_used w _Jv_RegisterClasses 0000000000606ce8 B DTOR_END 0000000000606dac A bss_start 0000000000606d40 D __data_start w __deregister_frame_info 0000000000405628 R __dso_handle w __gmon_start 0000000000401161 T __libc_csu_fini 0000000000401150 T __libc_csu_init 00000000004010ab T __libc_start_main w __register_frame_info 0000000000401f2d T __stack_chk_fail 0000000000606dac A _edata 000000000060af48 A _end 0000000000405608 T _fini 0000000000400164 T _init 0000000000400180 T _start 0000000000606d40 W data_start 0000000000606da8 D dmtcp_info_jassertlog_fd 0000000000606da4 D dmtcp_info_stderr_fd 0000000000606e10 B environ 0000000000401d75 T getenv 00000000004002a1 T main 0000000000401ec9 T memcpy 0000000000401efa T memset 0000000000606e20 B saved_pid }}}
After looking at closer that is what I thought, but I figured better to ask just in case.
I guess we don't need vote on this one.
Login to comment on this ticket.