Duplicate symbols when linking on Mac OSX

[JD Arnold]

Wondering if I'm the only one doing it this way? 

I am using the release branch 69 on Mac OSX. Here's my gn line:

gn gen out/release_mac --args="is_debug=false rtc_build_ssl=false rtc_ssl_root=\"/Users/jda/iocommain/External/openssl/insors/include\" target_os=\"mac\" target_cpu=\"x64\" rtc_build_tools=false rtc_include_tests=false mac_min_system_version=\"10.9.0\" use_rtti=true"

As you can see, I'm using our own OpenSSL v1.1.0h build. I had to add the use_rtti=true because otherwise I got a weird linker error ("typeinfo for rtc::LogSink", referenced from:")

So I've gotten a little further. Now I get a billion (well, to be exact, 720) duplicate symbols when I link our app. They are all related to Openssl, and it is complaining that all these OpenSSL symbols are declared in both my OpenSSL library and libwebrtc.a. If I rebuild libwebrtc.a and hit Ctrl-C so I can look at the .rsp file, I see all these boringSSL objects getting included. 

How do I avoid this?

Jonathan

[Alexandre GOUAILLARD]

Hi JD,

OpenSSL is not officially supported by Google, and you re going down a painful path, but here is how to do it if you feel like it:

- it's BoringSSL OR OpenSSL , you can't have both.

- you need to modify all the projects otherwise linking against boringSSL (at least libsrtp and usrsctp in /thirdparty).

- you will need to patch heavily the code in the following files:

--- a/rtc_base/openssladapter.cc

--- a/rtc_base/openssldigest.cc

--- a/rtc_base/openssldigest.h

--- a/rtc_base/opensslidentity.cc

--- a/rtc_base/opensslstreamadapter.cc

As a sanity check, you should run the corresponding unit tests (rtc_unittest executable).

You can see e.g. the test results on our daily builds of custom libwebrtc with OpenSSL 1.1.0g:

https://my.cdash.org/testDetails.php?test=41518952&build=1504469

If you're interested in getting pre-compiled, tested, packaged (cmake) versions, we can speak offline.

--

---
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/806a4bfa-bf46-4cbc-927b-3c9e3153fe6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[JD Arnold]

That can't be true. Compiling against OpenSSL even has a couple very specific gn (rtc_build_ssl rtc_ssl_root) options. And given that Google tells you to *not* use Boring SSL in your own projects, I don't see how I can link against the webrtc library and also use SSL in my own app. And it works fine on Windows. I did get this to sort of work by hitting Ctrl-C when it was building the library, hand editing the .rsp file, and re-running the same library steps. This had the added benefit of shrinking the resulting .a file from over 300mb down to less than 60mb, as I also removed all mention of video and rtcp files.

But that doesn't seem to be a sustainable option.