Re: [tor-bugs] #23846 [Core Tor/Tor]: Use libtool for building shared library

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#23846: Use libtool for building shared library
-------------------------------------------------+-------------------------
 Reporter:  hellais                              |          Owner:  sbs
     Type:  enhancement                          |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.4.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                               |
Parent ID:  #25510                               |         Points:
 Reviewer:  ahf                                  |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by sbs):

 Regarding linking Rust generated code and `-fPIC` code, there is this
 additional data point. The rust developer themselves acknowledge that they
 use `-fPIC` for static libraries on github, explain why that is the
 default, and how to disable `-fPIC` [1].

 (I originally wrote a much longer comment but I would like to do more
 research before writing libtool-related statements of which I am not 100%
 sure yet.)

 I would perhaps add that, after having worked a little more on this issue,
 I have a sense that what we actually need for mobile is mainly a _single_
 `.a` archive compiled with `-fPIC` code and a header. At least, this is
 exactly what we need on Android (for iOS I need to double check whether we
 can get away without `-fPIC`, but since Android needs `-fPIC`, I'd say we
 need `-fPIC`).

 In this regard, the main reason to use libtool is that it seems (based on
 my research, can provide more pointers if needed) the most portable, less
 hackish way to assemble several `.a` files (through `.la` or, with the
 aforementioned warning, using `.a` generated by Rust).

 I'm hoping to dedicate more on this ticket this week and would like to do
 the following:

 1. make a simple iOS and Android apps using the `.a` library and confirm
 it works

 2. make sure it also works on Windows 10 (which is what I have :-)

 Regarding the latter point, what is the reference build system? In
 addition to MSVC, I also use MSYS2 with mingw-w64 on Windows. Would MSYS2
 be okay as a build system to test?

 Also, is there interest in adding CI using AppVeyor? If so, I can probably
 try to add an `appveyor.yml` to my fork on github and try building with
 MSYS2. Then, if it's okay, also that patch can be upstreamed. Would that
 be of interest?

 Final question: integration would be further simplified if there was an
 autoconf/automake rule to install the static library and the header. Would
 a third diff adding that be accepted? (We have scripts that compile and
 install all dependencies in a specific location and not having rules to
 install means writing bash to copy the library and headers -- not a big
 deal but less smooth.)

 [1] https://github.com/rust-lang/rust/issues/27142

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs