Opened 12 years ago

Closed 14 months ago

#507 closed defect (fixed)

tor-gencert linked against event/pthread

Reported by: weasel Owned by: rl1987
Priority: Very Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: 0.2.0.5-alpha
Severity: Normal Keywords: automake tor-client tor-common refactor modules
Cc: weasel, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

tor-gencert is linked against libevent and libpthread tho it probably doesn't need those.
Since tor-gencert is quite a file that you might want to transfer to a computer that
doesn't have libevent it would be nice if it could not be linked against that library.

Unless of course it needs libevent.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (12)

comment:1 Changed 12 years ago by nickm

It doesn't need those libs, but it links against some files in src/common/ that have other functions that use
libevent and pthreads. I agree that it would be nice to split this stuff out (especially since tor-resolve doesn't need
libevent or pthreads either), but I don't have a good handle on how much refactoring we'd need.

I'm pretty sure all the libevent stuff in common is in a function to install a log callback in src/common/log.c.
Threads, on the other hand, mainly in compat.c, but I'm pretty sure that other files use them too. It might be nice
to split out the functions that need these libraries into separate .a libraries, so that tor-resolve and tor-gencert
don't need to link them.

OTOH, the userbase for tor-resolve is going to get smaller with the arrival of DNSPort, and the userbase for tor-gencert
is not likely to get very big ever. So maybe this should be a "Feel Free!" kind of situation.

comment:2 Changed 9 years ago by nickm

Description: modified (diff)
Keywords: easy automake added
Milestone: post 0.2.1.xTor: 0.2.3.x-final

The solution here is to split off the threading functions into a libor-threads.a, just like libor.a and libor-crypto.a and libor-event.a are currently split. If somebody wanted to, they could also split libor-crypto.a into libor-ssl.a and libor-crypto.a.

Should be easy enough to do.

comment:3 Changed 9 years ago by nickm

just like libor.a and libor-crypto.a and libor-event.a are currently split

Oops; it looks like we no longer even need to link the src/tools stuff against libevent. Fixed in master. /me is too cowardly to backport this.

The pthreads tweak is bigger, and will require splitting at least src/common/compat*. We should hold off there while the multicrypto branch is up in the air, since that is going to wind up adding and refactoring a fair bit of threads stuff, and it won't merge cleanly if the code gets moved.

comment:4 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:5 Changed 7 years ago by nickm

Keywords: easy,automakeeasy automake

comment:6 Changed 7 years ago by nickm

Keywords: tor-client added

comment:7 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:8 Changed 4 years ago by nickm

Cc: weasel,nickmweasel, nickm
Points: small

comment:9 Changed 2 years ago by nickm

Keywords: tor-common refactor modules added; easy removed
Points: small
Severity: Normal

This is actually likely to fall out of a much bigger but more important ticket -- refactoring src/common so that each sub-library is well isolated from the others. Once that's done, tor-gencert can trivially link against only the ones it needs.

comment:10 Changed 18 months ago by Hello71

this is fixable on Linux by -Wl,--as-needed with either -flto or -ffunction-sections -Wl,--gc-sections. seems to work on freebsd too, but probably not Mac or Windows.

comment:11 Changed 14 months ago by rl1987

Owner: set to rl1987
Status: newaccepted

comment:12 Changed 14 months ago by rl1987

Resolution: Nonefixed
Status: acceptedclosed

It seems that after recent refactoring it no longer links libpthread and libevent:

$ objdump -macho -dylibs-used src/tools/tor-gencert
src/tools/tor-gencert:
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/local/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/usr/local/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
Note: See TracTickets for help on using tickets.