libwebrtc-sys conflicting with openssl-sys #89
Assignees
Labels
Comments
|
Hey, this is definitely a tricky issue, thanks for the report! Multiple things here:
|
theomonnom
added
good first issue
|
This seems related: sfackler/rust-openssl#1526 |
My current setup does not have any of those flags set, so most likely it is not related to the livekit crate's feature set.
Yes, reqwest is one of the libraries that will conflict with it. I put together a minimal modification of the basic_room example that exhibits the behavior. I have tested it on my local Gentoo linux system with OpenSSL 3.0.9 as well as a Ubuntu 22.04 environment. The backtrace I have seen on multiple systems is:
Sure, the basic idea is:
See this patch for what I have done locally to the build of libwebrtc. There's currently something missing from that patch since there are 2 undefined symbols when building but I can fix it up later if it helps. Either way, this was just a proof of concept and it would probably be the better option if the build of BoringSSL into libwebrtc could be adjusted so that it doesn't interfere with other SSL libraries. |
|
Hey, I just tested your example, and I couldn't reproduce the issue. I had to modify the dependencies to use a vendored version. (It seems to only happen when using vendored versions). |
|
I think using BoringSSL and OpenSSL in the same binary is bad practice. IMO the best way to fix this would be to use custom webrtc builds with these arguments: This will make WebRTC uses OpenSSL instead of BoringSSL |
There might be something differing between our configurations. Here's a Containerfile that I put together that builds my branch demonstrating the conflict: FROM ubuntu:22.04 as builder
RUN apt-get update
RUN apt-get install -y \
build-essential \
cpio \
git \
grpc-proto \
libgl-dev \
libprotobuf-dev \
libssl-dev \
libx11-dev \
libxext-dev \
ninja-build \
pkg-config \
protobuf-compiler \
python-all-dev \
python3 \
python3-setuptools \
wget \
''
RUN useradd -ms /bin/bash builder
USER builder
RUN wget https://sh.rustup.rs -O - | sh -s -- -y
ENV PATH="/home/builder/.cargo/bin:/usr/bin:/bin:/usr/sbin:/sbin"
WORKDIR /build
RUN git clone https://github.com/jyelloz/livekit-client-sdk-rust.git
WORKDIR livekit-client-sdk-rust
RUN git checkout openssl-boringssl-conflict
RUN git submodule update --init
WORKDIR /build/livekit-client-sdk-rust/examples/basic_room
RUN cargo build
FROM ubuntu:22.04
COPY --from=builder /build/livekit-client-sdk-rust/examples/target/debug/basic_room /
CMD ["/basic_room"]If you build with something like |
|
I believe that I am having the same issue. Host: M1 MacOS I cleared by crates/cargo cache, pulled down a fresh clone of the "client-sdk-rust" repo and attempted a "cargo build" and run of the bin. Bin is too big to attach. I have attached a full BT zipped up. I am not entirely clear on the process for working around this issue. Any additional details would be appreciated. |
|
Per a suggestion, I also used the precompiled FFI and tested on python in the same ARM docker container. This seemed to work just fine. It would appear that compiling and running a rust app on arm linux (ubuntu) seems to be the issue. |
|
Ok, I was able to get a successful test of the basic_room example. I needed to use the livekit feature "rustls-tls-native-roots". Without it I would get an expected "TisFeatureNotEnabled" error and the tis-native seg faults. |
|
One last update, I am a bit stuck. At this point I am unable to use reqwest lib and livekit in the same application. It doesn't seem to matter what combination of features is used. I end up with the same seg fault. Please advise on if there is a workaround. Thanks! |
|
Hey, as a temporary workaround, you can try to avoid having openssl in your builds. (You can check the dependencies using cargo tree). You can see it is working when I'm not using native-tls (no openssl in the tree) 223,250d222
< │ │ │ ├── hyper-tls v0.5.0
< │ │ │ │ ├── bytes v1.4.0
< │ │ │ │ ├── hyper v0.14.27 (*)
< │ │ │ │ ├── native-tls v0.2.11
< │ │ │ │ │ ├── log v0.4.19
< │ │ │ │ │ ├── openssl v0.10.57
< │ │ │ │ │ │ ├── bitflags v2.3.3
< │ │ │ │ │ │ ├── cfg-if v1.0.0
< │ │ │ │ │ │ ├── foreign-types v0.3.2
< │ │ │ │ │ │ │ └── foreign-types-shared v0.1.1
< │ │ │ │ │ │ ├── libc v0.2.147
< │ │ │ │ │ │ ├── once_cell v1.18.0
< │ │ │ │ │ │ ├── openssl-macros v0.1.1 (proc-macro)
< │ │ │ │ │ │ │ ├── proc-macro2 v1.0.66 (*)
< │ │ │ │ │ │ │ ├── quote v1.0.32 (*)
< │ │ │ │ │ │ │ └── syn v2.0.28 (*)
< │ │ │ │ │ │ └── openssl-sys v0.9.93
< │ │ │ │ │ │ └── libc v0.2.147
< │ │ │ │ │ │ [build-dependencies]
< │ │ │ │ │ │ ├── cc v1.0.79 (*)
< │ │ │ │ │ │ ├── pkg-config v0.3.27
< │ │ │ │ │ │ └── vcpkg v0.2.15
< │ │ │ │ │ ├── openssl-probe v0.1.5
< │ │ │ │ │ └── openssl-sys v0.9.93 (*)
< │ │ │ │ ├── tokio v1.29.1 (*)
< │ │ │ │ └── tokio-native-tls v0.3.1
< │ │ │ │ ├── native-tls v0.2.11 (*)
< │ │ │ │ └── tokio v1.29.1 (*)
254d225
< │ │ │ ├── native-tls v0.2.11 (*)
276d246
< │ │ │ ├── tokio-native-tls v0.3.1 (*)
307c277,278
< │ │ │ ├── native-tls v0.2.11 (*)
---
> │ │ │ ├── rustls v0.21.5 (*)
> │ │ │ ├── rustls-native-certs v0.6.3 (*)
309c280
< │ │ │ ├── tokio-native-tls v0.3.1 (*)
---
> │ │ │ ├── tokio-rustls v0.24.1 (*)
317d287
< │ │ │ ├── native-tls v0.2.11 (*)
326a297
> │ │ │ ├── rustls v0.21.5 (*)
|
|
So the best solution would be to build webrtc with openssl, seems like this isn't straightforward to do. |
|
I believe we're hitting this issue in Zed on Linux, when trying to integrate this crate. We're using the The backtrace of the crashed thread is: |
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, I have been using this SDK recently, though after testing it a bit further a problem was encountered where an application depending on the SDK crashes while attempting to initialize OpenSSL when running in Ubuntu 22.04. It works fine on my Fedora 38 system, however.
I found that this is caused by libwebrtc-sys statically linking in BoringSSL code which conflicts with the dynamically linked OpenSSL symbols that other crates in the same application depend on. Furthermore, attempting to enable the various "vendored" features in other TLS provider crates will result in the application failing to link due to conflicting symbol names. I was able to get around the problem by modifying libwebrtc's build in a few places to prevent it from building any BoringSSL code, allowing for openssl-sys to fill that dependency. Are there any plans to un-bundle the TLS library from libwebrtc-sys or prevent the private symbols in libwebrtc from reaching outside of the libwebrtc-sys crate?
The text was updated successfully, but these errors were encountered: