How to exclude the Openssl logic at webrtc source code ?

110 views
Skip to first unread message

zhao...@gmail.com

unread,
Sep 22, 2022, 5:17:01 PM9/22/22
to discuss-webrtc
I am trying to develop my linux app. which utilizes webrtc's data channel via static library : libwebrtc.a

At my app. , it contains my own websocket implementation which has nothing to do with webrtc or boringssl.
( It is based on Openssl )

Unfortunatly , my  app. got segment fault once it tried to establish websocket connection :

(openssl_key_pair.cc:40): Making key pair
(openssl_key_pair.cc:93): Returning key pair
(boringssl_certificate.cc:189): Making certificate for WebRTC
(boringssl_certificate.cc:245): Returning certificate
Segmentation fault (core dumped)

I am still trying to figure out what the above modules are and how come my own websocket implementation gets involved with webrtc's library.

Is it possible to get rid of these modules ? Are they needed for data channel ? ( I only need data channel from webrtc ,no audio or video )

Regards !

Sean DuBois

unread,
Sep 22, 2022, 6:05:37 PM9/22/22
to discuss...@googlegroups.com

On Sep 22, 2022, at 17:17, zhao...@gmail.com <zhao...@gmail.com> wrote:

I am trying to develop my linux app. which utilizes webrtc's data channel via static library : libwebrtc.a
--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/a5f4fe6f-9054-4edb-a7f3-fed3e7e4766bn%40googlegroups.com.

Philipp Hancke

unread,
Sep 23, 2022, 1:18:16 AM9/23/22
to discuss...@googlegroups.com
Configuring the build with
rtc_build_ssl=false
rtc_ssl_root=\"/usr/include\""
via gn should do the trick. Note that this isn't the most tested path so might bump into issues like


--

V I

unread,
Sep 23, 2022, 4:02:11 AM9/23/22
to discuss...@googlegroups.com
A libwebrtc rule of thumb: if it's not how it's built for Chrome, it's broken. Pointing other libs to libwebrtc's BoringSSL (which is still pretty much identical to OpenSSL it was forked from API-wise) worked the best for me

Reply all
Reply to author
Forward
0 new messages