[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #9711 [Tor bundles/installation]: Test out crosstools-ng for Gitian OSX builds (instead of toolchain4 binaries)

#9711: Test out crosstools-ng for Gitian OSX builds (instead of toolchain4
binaries)
------------------------------------------+-------------------------------
     Reporter:  mikeperry                 |      Owner:  erinn
         Type:  task                      |     Status:  needs_information
     Priority:  normal                    |  Milestone:
    Component:  Tor bundles/installation  |    Version:
   Resolution:                            |   Keywords:  tbb-3.0, gitian
Actual Points:                            |  Parent ID:
       Points:                            |
------------------------------------------+-------------------------------

Comment (by gk):

 Replying to [comment:51 mingwandroid]:
 > I've concluded that libfaketime is somewhat broken for the use case that
 gitian build requires.
 >
 > Some problems I've seen include:
 >
 > 1. The fake time values are not setup correctly for early calls (at
 least in the MT version any that happen between semaphore creation and the
 getenv("FAKETIME")/getenv("FAKETIME_FMT") calls).
 > 2. Caching functionality is broken; it doesn't respect the "FAKETIME"
 env. var, merrily replacing it with "+0" instead as soon as it decides
 that the cached values are too old. This means that long running processes
 stop faking time properly early in their execution.
 > 3. nano-second values are never touched for the stat family of functions
 - or likely any that call fake_time - and gnumake uses nanoseconds for
 dependency checking. Without fixing this, the dependency timestamp check
 could be replaced with "rand()&1" (Mike's blog post mentions this in point
 4 of "Remaining Build Reproducibility Issues [Millisecond and below
 timestamps are not fixed by libfaketime]")
 >
 > I've got a messy patch for these issues that I can share?

 Sure. Best would probably be to file these issues upstream (or check
 whether they are already there). I can do both. Now, what are our options
 here? Accept building with
 {{{
 CT_PARALLEL_JOBS=1
 }}}
 until these issues are fixed? Trying to get the clang compiler working
 (which we probably need to to anyway, see #9829) and hoping we are getting
 away with that?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9711#comment:52>
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