Build a custom version of libcurl that is statically linked

[DemiMarie]

Libcurl (very annoyingly!) has a thread-unsafe startup function, curl_global_init.

Currently, this library recommends that curl be initialized very early in the program. But that still isn’t safe. A user could fail to initialize this library and then experience a data race (= undefined behavior) later on.

Rust has no way to ensure that a function is called before any threads are launched. Initializing libcurl from a static initializer can cause deadlocks on Windows. Is there a solution?

[alexcrichton]

Could you clarify the unsafety here? Invocations of the initialization function should be synchronized.

[alexcrichton]

AFAIK there's no known unsafety here, so I'm going to close this, but please let me know if I'm wrong!

[DemiMarie]

@alexcrichton The unsafety appears if another thread is already using one of the libraries that libcurl uses, and which has a thread-unsafe initialization, such that both threads try to initialize libcurl (or a dependency thereof) simultaneously.

[alexcrichton]

Indeed! Other crates I've worked in solve this by exposing a shared init function in the sys crate to call into, and I could add that to curl as well if needed!

[DemiMarie]

The problem is that we can't ensure that the init func is called first, since Rust lacks life before main() (and on Windows the loader lock means that there is no good way to do this). So we need a private copy of libcurl (and its dependencies) that we know nobody else will be using.

…

On May 9, 2017 7:11 PM, "Alex Crichton" ***@***.***> wrote: Indeed! Other crates I've worked in solve this by exposing a shared init function in the sys crate to call into, and I could add that to curl as well if needed! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB20ygcLbB8xgmMy7l8sELg3xXU3cks5r4PKcgaJpZM4M5GRO> .