[tor-bugs] #23846 [Core Tor/Tor]: Option to build Tor with -fPIC (Use libtool for building shared library?) (was: Use libtool for building shared library)

[Tor Bug Tracker & Wiki]

#23846: Option to build Tor with -fPIC (Use libtool for building shared library?)
-------------------------------------------------+-------------------------
 Reporter:  hellais                              |          Owner:  nickm
     Type:  enhancement                          |         Status:
                                                 |  accepted
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.5.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-mobile, s8-api,                  |  Actual Points:
  034-triage-20180328, 034-included-20180402,    |
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711                           |
Parent ID:  #25510                               |         Points:
 Reviewer:  ahf                                  |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by nickm):

 Replying to [comment:42 sbs]:
 > > Instead of a single static library, would a target that gives you a
 list of all the static libraries you need be acceptable?
 >
 > Yes, that would be acceptable!
 >
 > > [...] all the libraries you need to link for tor, in the correct
 order,
 >
 > This is especially useful because I was not super happy having to keep
 track of the correct order, especially in the future when switching to new
 releases; but having an authoritative source for the names and order is
 great.
 >
 > Is is correct to say that the reason why different `.a` libraries are
 built in tor, as opposed to a single library, is that you need to apply
 different compiler flags to different portions of the code base, or is
 there another reason?

 It's some of what you said here (different compiler flags); somewhat an
 attempt at enforcing modularity; and somewhat because some of our tools
 and testing programs only need smaller portions of the Tor codebase.

 > > [...] because Cargo builds its libraries as .lib rather than .a.
 >
 > Yeah, using non portable tricks was making me a little nervous because I
 feared something I was most likely not aware of could break.
 >
 > Curiosity: does this imply that rust produces binaries compatible with
 the format of MSVC as opposed to the one of GCC? Does this imply that
 MinGW is not used anymore for Windows, or is MinGW now able to cope with
 the format of MSVC?

 I believe that mingw can link against .lib libraries; I don't know whether
 this is a full-compability thing, or whether the compatibility is partial.

 Per
 https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SupportedPlatforms
 , msvc is still officially "Unsupported": We'll take clean patches to make
 it work, but we don't test with it or try hard to keep it working
 ourselves.

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