On 10/8/2018 2:09 AM, Karel Zak wrote:
I get the warning, but result is still static binary. Don't ask me whyl
;-)
$ file ./mount.static
./mount.static: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=b66bae970bf72346cbf6d844e0e48d5dbfd07cc2, with debug_info, not stripped
The problem is the way how glibc uses stuff around NSS. In this case
glibc needs runtime modules, for more details see...
But not for mount.static, apparently?
It seems the issue is only getpwnam_r() which is necessary only when
mount(8) translates gid=<name> to gid=<number>. It's rarely used
mount(8) feature.
I wonder if this works.
---
Anyway, could you send me your configure line?
FWIW, for mount.static, above, I am getting:
file mount.static
mount.static: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=563cbfb845525273cdb0eb8bb7b0d5bcc5613d80,
not stripped
^^^--ok, says dynamically linked, but w/what?
If I explicitly disable 'shared', I got what looked like all of util-linux
libs built-in, but still needing all external libs.
FWIW, if I try to test from the build location:
ldd .libs/mount
.libs/mount: /usr/lib64/libmount.so.1: version `MOUNT_2.33' not found
(required by .libs/mount)
.libs/mount: /usr/lib64/libmount.so.1: version `MOUNT_2.30' not found
(required by .libs/mount)
linux-vdso.so.1 (0x00007ffc8a77c000)
libmount.so.1 => /usr/lib64/libmount.so.1 (0x000000305ce00000)
libblkid.so.1 => //lib64/libblkid.so.1 (0x0000003002c00000)
libuuid.so.1 => //lib64/libuuid.so.1 (0x0000003002800000)
librt.so.1 => //lib64/librt.so.1 (0x0000003001c00000)
libc.so.6 => //lib64/libc.so.6 (0x0000003000800000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003016e00000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff504871000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003000c00000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x000000300b800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003001000000)
----
Did it used to be the case that dynamic linking would look in the
"current dir"
for libs? Seems like the above would break more situations of an in-place
lib being build & tested.
My switches:
../config-233rc1.sh --test
setting basic optimize
Running Config:
./configure -q "CFLAGS=-fpic -march=native -pipe -O2" "LDFLAGS=-fpic
-march=native -pipe -O2 -Wl,--stats " "--prefix=/ --bindir=/bin
--sbindir=/sbin --datadir=/usr/share --includedir=/include
--oldincludedir=/usr/include --libdir=/lib64
--libexecdir=/lib64/util-linux --localstatedir=/var
--sharedstatedir=/com --sysconfdir=/etc --enable-chfn-chsh
--enable-fs-paths-default --enable-last --enable-libmount-support-mtab
--enable-line --enable-login-chown-vcs --enable-login-stat-mail
--enable-newgrp --enable-pg --enable-silent-rules
--enable-static-programs=losetup,mount,umount,fdisk,sfdisk,blkid,nsenter,unshare
--enable-sulogin-emergency-mount --enable-vipw --enable-write
--disable-assert --disable-rpath --disable-nls
--disable-plymouth_support --disable-pylibmount --with-audit
--with-bashcompletiondir=/usr/share/bash-completion --with-gnu-ld
--with-ncursesw --with-readline --with-smack --without-python
--without-systemd --without-systemdsystemunitdir"
using gcc: gcc version 8.2.1 20180817 [gcc-8-branch revision 263612]
(SUSE Linux)
