0

I'm trying to build static binaries for net-tools-1.60, so they can run on their own on any system. I downloaded the source for net-tools from SourceForge and applied 3 patches. Then I compile successfully with make SHARED=0 CC='gcc -static'. The compiled binaries show as "statically linked" and some work, but some get "Segmentation Fault". Mainly arp and route are not working. I also tried LDFLAGS="--static" make -j 4, but the resulting binaries still show "dynamically linked".

This is on Ubuntu 16.04 with 4.4.0-64-generic kernel. Any ideas how to get this working?

Warnings

requires at runtime the shared libraries from the glibc version used for linking
/home/user/Desktop/net-tools-1.60/lib/inet.c:404: warning: Using 'setprotoent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/user/Desktop/net-tools-1.60/lib/inet.c:414: warning: Using 'endprotoent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/user/Desktop/net-tools-1.60/lib/inet.c:386: warning: Using 'getservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/user/Desktop/net-tools-1.60/lib/inet.c:385: warning: Using 'setservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/user/Desktop/net-tools-1.60/lib/inet.c:403: warning: Using 'endservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Crashes

user@ubuntu:~/Desktop/net-tools-1.60$ file arp
arp: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=fc19dbe5121b2a3eb7aee3e6e0fc8de7490d6263, not stripped
user@ubuntu:~/Desktop/net-tools-1.60$ ./arp 
Segmentation fault (core dumped)

GDB

(gdb) run
Starting program: /home/user/Desktop/net-tools-1.60/arp 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) where
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff6c83fa9 in __pthread_initialize_minimal_internal () at nptl-init.c:471
#2  0x00007ffff6c83589 in _init () at ../sysdeps/x86_64/crti.S:72
#3  0x00007ffff70a4670 in ?? () from /lib/x86_64-linux-gnu/libnss_myhostname.so.2
#4  0x00000000004acd5a in call_init.part ()
#5  0x00000000004acf15 in _dl_init ()
#6  0x00000000004999a5 in dl_open_worker ()
#7  0x0000000000497164 in _dl_catch_error ()
#8  0x0000000000499309 in _dl_open ()
#9  0x00000000004563d2 in do_dlopen ()
#10 0x0000000000497164 in _dl_catch_error ()
#11 0x00000000004565be in __libc_dlopen_mode ()
#12 0x0000000000451e6d in __nss_next2 ()
#13 0x000000000044dbac in gethostbyaddr_r ()
#14 0x000000000044d9be in gethostbyaddr ()
#15 0x00000000004031f2 in INET_rresolve (name=name@entry=0x6e68e0 <buff> "", sin=0x7fffffffd440, 
    numeric=<optimized out>, netmask=netmask@entry=4294967040, len=128) at inet.c:200
#16 0x0000000000403354 in INET_sprint (sap=<optimized out>, numeric=<optimized out>) at inet.c:246
#17 0x0000000000401877 in arp_show (name=0x0) at arp.c:581
#18 0x0000000000400b53 in main (argc=1, argv=0x7fffffffe008) at arp.c:768
(gdb)

Update So I just built the tools on an older Ubuntu 11.10 32bit. The resulting binaries are working fine on my Ubuntu 16.04 64bit. I think there might be a bug in 16.04.

user1781482
  • 623
  • 3
  • 15
  • 24

1 Answers1

1

The compiled binaries show as "statically linked" and some work, but some get "Segmentation Fault"

This is expected result (assuming the crashes are happening on a system other than the one where they were built).

Contrary to popular belief, fully-static libraries on Linux are less portable than dynamically linked ones.

You should have received a link-time warning looking like this:

warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Explanation.

Update:

The crashes are not expected on the same system on which the program was built. This crash looks like a GLIBC bug.

The end result is the same though: don't link statically; no good will come out.

Community
  • 1
  • 1
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Yes, there are some of those warnings. Can that be fixed? The idea is to run the tools from external disk without touching the system they will be ran on. BTW the crashes are happening on the same system I'm building on. Haven't tried on another computer. – user1781482 Mar 06 '17 at 02:31
  • 1
    @user1781482 Crashes on the *same* system are not expected. Edit your post to show the crash stack trace from GDB. – Employed Russian Mar 06 '17 at 02:40
  • I'm not sure how to see the crash stack trace. I'm not a pro. How do I do that? Thanks. – user1781482 Mar 06 '17 at 02:46
  • @user1781482 Try `gdb ./arp`, then `run`. Once GDB stops with `SIGSEGV`, use `where` command, and edit your question with the transcript of your GDB session. – Employed Russian Mar 06 '17 at 02:51
  • So are there any other alternatives? I'm trying to get a "portable" tool that will run entirely from external drive, system independent – user1781482 Mar 06 '17 at 03:11
  • @user1781482 Yes, the alternative that *works* is to link *dynamically* on an the oldest distribution you plan to support. http://stackoverflow.com/a/8658468/50617 – Employed Russian Mar 06 '17 at 03:21