2.51.0: some objects are without symbols
I'm building with enabled LT by passing to the configure scrip proper env variables like:
export CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fdata-sections -ffunction-sections}";
export CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fdata-sections -ffunction-sections}";
export FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules -flto=auto -flto-partition=none -fdata-sections -ffunction-sections}";
export FCFLAGS="${FCFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules -flto=auto -flto-partition=none -fdata-sections -ffunction-sections}";
export LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,--gc-sections}";
export AR="/usr/bin/gcc-ar" RANLIB="/usr/bin/gcc-ranlib" NM="/usr/bin/gcc-nm";
export CC="gcc" CXX="g++"
Observing build logs I found strange warning:
[tkloczko@barrel librsvg-2.51.0]$ rm librsvg-2.la; make librsvg-2.la
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fdata-sections -ffunction-sections -Wl,-Bsymbolic-functions -version-info 50:0:48 -export-dynamic -no-undefined -export-symbols-regex "^rsvg_.*" -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,--gc-sections -o librsvg-2.la -rpath /usr/lib64 librsvg_c_api.la -lpng16 -lz -lcairo-gobject -lgdk_pixbuf-2.0 -lgio-2.0 -lxml2 -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype -lm -ldl
libtool: link: rm -fr .libs/librsvg-2.exp .libs/librsvg-2.la .libs/librsvg-2.lai .libs/librsvg-2.so .libs/librsvg-2.so.2 .libs/librsvg-2.so.2.48.0 .libs/librsvg-2.ver
libtool: link: /usr/bin/gcc-nm ./.libs/librsvg_c_api.a | sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /usr/bin/sed 's/.* //' | sort | uniq > .libs/librsvg-2.exp
/usr/bin/nm: rustc_std_workspace_alloc-ea332f4c2861957c.rustc_std_workspace_alloc.9oldb3qu-cgu.0.rcgu.o: no symbols
/usr/bin/nm: cfg_if-e8489c1f15fbb688.cfg_if.cw557s6l-cgu.0.rcgu.o: no symbols
/usr/bin/nm: rustc_std_workspace_core-16106dedcf2b37fb.rustc_std_workspace_core.4mvbp8e6-cgu.0.rcgu.o: no symbols
libtool: link: /usr/bin/grep -E -e "^rsvg_.*" ".libs/librsvg-2.exp" > ".libs/librsvg-2.expT"
libtool: link: mv -f ".libs/librsvg-2.expT" ".libs/librsvg-2.exp"
libtool: link: echo "{ global:" > .libs/librsvg-2.ver
libtool: link: cat .libs/librsvg-2.exp | sed -e "s/\(.*\)/\1;/" >> .libs/librsvg-2.ver
libtool: link: echo "local: *; };" >> .libs/librsvg-2.ver
libtool: link: gcc -shared -fPIC -DPIC -Wl,--whole-archive ./.libs/librsvg_c_api.a -Wl,--no-whole-archive -lpng16 -lz -lcairo-gobject -lgdk_pixbuf-2.0 -lgio-2.0 -lxml2 -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype -lm -ldl -O2 -g -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -flto=auto -flto-partition=none -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,--gc-sections -Wl,-soname -Wl,librsvg-2.so.2 -Wl,-version-script -Wl,.libs/librsvg-2.ver -o .libs/librsvg-2.so.2.48.0
libtool: link: (cd ".libs" && rm -f "librsvg-2.so.2" && ln -s "librsvg-2.so.2.48.0" "librsvg-2.so.2")
libtool: link: (cd ".libs" && rm -f "librsvg-2.so" && ln -s "librsvg-2.so.2.48.0" "librsvg-2.so")
libtool: link: ( cd ".libs" && rm -f "librsvg-2.la" && ln -s "../librsvg-2.la" "librsvg-2.la" )
As you see proper $NM (/usr/bin/gcc-nm) is used however from underneath when /usr/bin/nm is executed it reports some .o files without symbols.
I've umpacked .libs/librsvg_c_api.a
and file
command shows that three .o files in that archive are really without symbols.
$ file *.o | grep -v "not stripped"
cfg_if-e8489c1f15fbb688.cfg_if.cw557s6l-cgu.0.rcgu.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
rustc_std_workspace_alloc-ea332f4c2861957c.rustc_std_workspace_alloc.9oldb3qu-cgu.0.rcgu.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
rustc_std_workspace_core-16106dedcf2b37fb.rustc_std_workspace_core.4mvbp8e6-cgu.0.rcgu.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
It is only warning and maybe effectively nothiong is compiled into those .o files.
It looks strange and I'm looking only for kind of second opinion/expertise ..