Snowflake broken if no libatomic on host

[isabela]

OS: Debian stretch

TB alpha 7.5a8

Tor Browser logs:

​https://share.riseup.net/#H0k8k6BxXvsOGMq2CODCfg

steps to reproduce error:

1. click on configure

2. select snowflake

3. try to connect

4. error shows up (screenshot: https://trac.torproject.org/projects/tor/attachment/ticket/24465/error-screenshot-snowflake-missing.png)

[isabela]

screenshot of error - snowflake missing

[gk]

Works for me on a Debian system with a clean 7.5a8. Have you tried with a fresh bundle as well?

Another user on #tor today confirmed that snowflake on Linux with Tor Browser 7.5a8 worked around a Tor block done by the local university.

[mcs]

For what its worth, I am also unable to reproduce this. I tried on an Ubuntu 14.04.5 system with a Tor Browser that was upgraded from 7.5a6 to 7.5a8.

I wonder if snowflake-client is crashing or refusing to start, and why.

[cypherpunks]

The issue seems to be reproducible per the info provided in duplicate #25087.

[gk]

Adding to our March plate.

[gk]

boklm: Could you test (using steps in #25087) whether the GCC update in #25304 solves this issue?

[boklm]

Replying to gk:

boklm: Could you test (using steps in #25087) whether the GCC update in #25304 solves this issue?

After the gcc update, snowflake-client is still linked to libatomic.so.1, so it seems it didn't solve the issue.

[gk]

Moving remaining tickets to May.

[gk]

Moving our tickets to June 2018

[gk]

More tickets for July.

[gk]

Move our tickets to August.

[sukhbir]

For review:

​https://github.com/azadi/tor-browser-build-1/tree/bug-24465

Note that this simply copies the library from gcc/libs. Perhaps we can do something similar for #25485, where we first try to run snowflake-client and if it fails, then only we add it libatomic.so to LD_LIBRARY_PATH. Is that preferred?

I reproduced and tested this on Lubuntu 17.10.

[gk]

Replying to sukhbir:

For review:

​https://github.com/azadi/tor-browser-build-1/tree/bug-24465

IIRC this was a 64bit-only problem but you are copying the lib for 32bit as well which seems to be not needed (if I got the history of this bug right).

Note that this simply copies the library from gcc/libs. Perhaps we can do something similar for #25485, where we first try to run snowflake-client and if it fails, then only we add it libatomic.so to LD_LIBRARY_PATH. Is that preferred?

We could do that. But we eventually want to get rid of LD_LIBRARY_PATH I think and not add another workaround to this workaround if possible. So, I wonder if this bug would be a good start to look into compiling with a relative -rpath. See: #13373 and #13359 where I did some initial work some years ago.

I reproduced and tested this on Lubuntu 17.10.

[gk]

Moving our tickets to September 2018

[sukhbir]

Replying to gk:

Replying to sukhbir:

For review:

​https://github.com/azadi/tor-browser-build-1/tree/bug-24465

IIRC this was a 64but-only problem but you are copying the lib for 32bit as well which seems to be not needed (if I got the history of this bug right).

The original logs had expired (the share.riseup.net link) so I decided to check and it seems like this issue affects both the 32- and 64-bit versions.

The branch with the rebased changes is at ​https://github.com/azadi/tor-browser-build-1/tree/bug-24465-rev1

[gk]

If just snowflake requires libatomic.so then let's make sure the library does not get unconditionally included but only if we are actually building and distributing snowflake (which is not the case for the current release series and might still not be the case for the coming one). We have var/snowflake for that.

[gk]

There is no GCC involved anymore in compiling dependencies for snowflake. Thus, I think with the purely Go-based version we have right now (see: #25483). This bug is gone, too.