#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
-----------------------------------+-----------------------------------
Reporter: cypherpunks | Owner: tbb-team
Type: defect | Status: needs_information
Priority: Medium | Milestone:
Component: Obfuscation/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------------+-----------------------------------
Comment (by yawning):
Replying to [comment:11 arma]:
> Speaking of atomic, there's an intriguingly related ChangeLog entry to
Tor itself in 0.3.3.1-alpha:
> {{{
> - Use stdatomic.h where available, rather than mutexes, to implement
> atomic_counter_t. Closes ticket 23953.
> }}}
> But on first glance it looks like that's headers, not the library. But,
does that mean that if Tor Browser builds Tor on a system with libatomic
headers, then Tor Browser's Tor will expect a libatomic it can use?
"Depends". libatomic is what GCC will fall back to if does not have
native code generation capability for an atomic operation on a given
target. If Tor Browser is targeting something where GCC ends up doing
that, then yes, Tor Browser's Tor will also expect a working libatomic.
> as we wait maybe everybody will get libatomic.
In an ideal world, GCC will support the relevant code generation for all
the targets that the bundle is shipped for, and no one will need
libatomic.
After thinking about this for a bit, I'm of the opinion that as long as
the GCC used to build Tor Browser generates code that links to it, Tor
Browser should bundle it, much like how libstdc++ is bundled.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25087#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online