Opened 8 years ago

Closed 2 years ago

#5683 closed enhancement (wontfix)

add libtool support to tor

Reported by: rsavoye Owned by:
Priority: Medium Milestone: Tor: 0.3.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, autotools, build, modularity, review-group-34
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Using libtool standardizes building shared or static libraries in a portable manner.

Child Tickets

Change History (20)

comment:1 Changed 8 years ago by rsavoye

Status: newneeds_review

This branch has libtool support now:

comment:2 Changed 8 years ago by arma

Component: Tor SupportTor Client

comment:3 Changed 8 years ago by runa

Owner: changed from runa to arma
Status: needs_reviewassigned

comment:4 Changed 8 years ago by runa

Status: assignedneeds_review

comment:5 Changed 8 years ago by arma

Owner: arma deleted
Status: needs_reviewassigned

comment:6 Changed 8 years ago by arma

Status: assignedneeds_review

fun with trac :/

comment:7 Changed 8 years ago by Sebastian

We should make sure we know of the possible sideffects here. obfsproxy had some unpleasantries with build changes

comment:8 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-final

This is not gonna happen in 0.2.3.x.

In 0.2.4.x, we need to see what the actual advantages are. Is there any place where our current approach is _not_ working?

FWIW, currently, we don't build shared libs at all. If we wanted to start, then I would be all in favor of libtool.

comment:9 Changed 8 years ago by rsavoye

Adding libtool shouldn't create any problems at all. While for static libraries it isn't needed, it does make tor behave in a similar manner to other projects. Plus if you ever do want to use shared libraries (nice when debugging), then it's a trivial change to allow that.

For obfsproxy, I do have a patch that adds libtool support to that package, which fixed the issue with shared library flags when using mingw for both cross and native builds.

comment:10 Changed 8 years ago by arma

How to proceed?

comment:11 in reply to:  10 Changed 8 years ago by nickm

Replying to arma:

How to proceed?

Decide whether we want the ability to build shared libraries. If so, we want this but have some other stuff to do to ensure that our shared libs get built correctly, that we have the option of _not_ using shared libs, and so forth. If not, there isn't a lot we need this for right now.

comment:12 Changed 8 years ago by arma

Ok. I'll leave the 'whether we want it' choice up to you. I do my best not to follow build stuff.

comment:13 Changed 8 years ago by rsavoye

Libtool is reasonably mature, and well tested for building shared libraries, it's hard to build shared libraries on a large variety of platforms without it. It also builds DLLs correctly for mingw32, You can build only static libraries using the configure options of --disable-shared, or to get both, --enable-static. I can also tweak the libtool config to produce static libraries by default. It's still useful as it makes the support for building libraries clearer.

comment:14 Changed 8 years ago by nickm

Keywords: tor-client added

comment:15 Changed 8 years ago by nickm

Component: Tor ClientTor

comment:16 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: unspecified

comment:17 Changed 3 years ago by nickm

Keywords: autotools build modularity added
Severity: Normal

comment:18 Changed 2 years ago by teor

Milestone: Tor: unspecifiedTor: 0.3.4.x-final

Move all needs_review tickets without a release to 0.3.4

comment:19 Changed 2 years ago by nickm

Keywords: review-group-34 added

comment:20 Changed 2 years ago by asn

Resolution: wontfix
Status: needs_reviewclosed

No plan to add libtool right now. We might revise during the modularization project, but this ticket not actionable anymore. Also rsavoye's code is no longer available in his github. Closing this ticket to reduce ticket pile, and let's reopen it or make a new one if we design to support libtool.

Note: See TracTickets for help on using tickets.