[tor-bugs] #6623 [Tor Relay]: --enable-static-tor cannot succeed

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Fri Aug 17 15:16:24 UTC 2012


#6623: --enable-static-tor cannot succeed
-------------------------+--------------------------------------------------
 Reporter:  tmpname0901  |          Owner:                    
     Type:  defect       |         Status:  new               
 Priority:  normal       |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Relay    |        Version:  Tor: 0.2.3.20-rc  
 Keywords:               |         Parent:                    
   Points:               |   Actualpoints:                    
-------------------------+--------------------------------------------------
 Build environment: CentOS v5.8/x86_64 with GCC v4.4.6.

 Use of the --enable-static-tor cannot result in a successful build, at
 least not with GLibC v2.5.

 Use of this flag causes the --static switch to be placed on the compiler
 command line when running tests from the configure script.  So when the
 script tries to verify, say, a working libevent library, the test fails.
 Then the script falsely believes that the intended test (e.g. finding a
 linkable libevent lib) has failed.  The actual failure is the inability to
 staticly link GLibC.

 Here's as example:

 $ gcc44 -o /tmp/conftest -static
 -I/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/include
 -I${top_srcdir}/src/common
 -L/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib
 -L/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib /tmp/conftest.c
 -lpthread -ldl -lrt -levent
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(evutil.o):
 In function `test_for_getaddrinfo_hacks':
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/evutil.c:1105:
 warning: Using 'getaddrinfo' in statically linked applications requires at
 runtime the shared libraries from the glibc version used for linking
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(evutil.o):
 In function `evutil_unparse_protoname':
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/evutil.c:758:
 warning: Using 'getprotobynumber' in statically linked applications
 requires at runtime the shared libraries from the glibc version used for
 linking
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(event.o):
 In function `gettime':
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/event.c:366:
 undefined reference to `clock_gettime'
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(event.o):
 In function `detect_monotonic':
 /home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/event.c:336:
 undefined reference to `clock_gettime'

 Ouch! Guess it couldn't find a working libevent.a, right?  Wrong!

 What linker couldn't do is staticly link GLibC's runtime libraries.
 Remove that --static from the command line and the configure script's test
 succeeds in linking against the specified static libevent library.

 Tor can be successfully linked against static zlib/openssl/libevent
 libraries but it cannot be staticly linked against gLibC.  This makes
 --enable-static-tor pointless, a least for Linux builds.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6623>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list