rtc_shared_library ?

[Kunal Jathal]

I've discovered about the 'rtc_shared_library' GN template and seen occurrences of it in multiple BUILD.GN files, but I'm still not sure how to actually 'invoke' the template -- I can't find any relevant arguments I can pass to the gn call...  i.e. how do I actually build a shared version of the webrtc library for windows?

I'm very new to gn/ninja, so I'm sure this is a stupidly simple question...

[Alexandre GOUAILLARD]

this variable is internal,

it's a copy of the chrome mechanism, prefixed with rtc to differentiate it.

it is only used in definition of targets.

the only variables you can modify from "outside" the build are the one passed to "gn gen", a.k.a. the "build args".

you can see which one you used (or the default ones)  by using the following command: "gn arg <build_directory>"

you can (but I would advise against it) list all of them, by using the following command: "gn arg <build_directory> --list --short"

you can (but i would advise against it) list all of them, with description by dropping the "--short" in the previous command.

At this stage, I would recommend you only list the rtc ones, and or, read the output of: "gn help buildargs"

The path you are trying to go down now is long and perilous, you can contact me offline if you want some commercial support. It could save you a lot of time.

E.G. the dll on windows are not so much about shared libs vs static libs, but more about which symbols you're going to (dll_)export.

rtc_audio_device_plays_sinus_tone = false

rtc_build_examples = true

rtc_build_json = true

rtc_build_libevent = false

rtc_build_libsrtp = true

rtc_build_libvpx = true

rtc_build_opus = true

rtc_build_ssl = true

rtc_build_tools = true

rtc_build_usrsctp = true

rtc_build_with_neon = false

rtc_builtin_ssl_root_certificates = true

rtc_enable_android_aaudio = false

rtc_enable_bwe_test_logging = false

rtc_enable_external_auth = false

rtc_enable_libevent = false

rtc_enable_protobuf = true

rtc_enable_sctp = true

rtc_enable_symbol_export = false

rtc_exclude_field_trial_default = false

rtc_exclude_metrics_default = false

rtc_include_ilbc = true

rtc_include_internal_audio_device = true

rtc_include_opus = true

rtc_include_pulse_audio = true

rtc_include_tests = true

rtc_jsoncpp_root = "//third_party/jsoncpp/source/include"

rtc_libvpx_build_vp9 = true

rtc_link_pipewire = false

rtc_link_task_queue_impl = true

rtc_opus_support_120ms_ptime = true

rtc_opus_variable_complexity = false

rtc_prefer_fixed_point = false

rtc_sanitize_coverage = ""

rtc_ssl_root = ""

rtc_use_dummy_audio_file_devices = false

rtc_use_gtk = true

rtc_use_h264 = false

rtc_use_lto = false

rtc_use_metal_rendering = true

rtc_use_pipewire = false

rtc_use_x11 = false

On Fri, Jun 21, 2019 at 8:46 AM Kunal Jathal <vzw.kuna...@gmail.com> wrote:

I've discovered about the 'rtc_shared_library' GN template and seen occurrences of it in multiple BUILD.GN files, but I'm still not sure how to actually 'invoke' the template -- I can't find any relevant arguments I can pass to the gn call...  i.e. how do I actually build a shared version of the webrtc library for windows?

I'm very new to gn/ninja, so I'm sure this is a stupidly simple question...

--

---
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/af457018-362f-4a34-ab8f-58f85597475a%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

• 
  

[Kunal Jathal]

Thanks for your reply. Yes, I've noticed the list of all the 'external' variables that I am able to modify from the outside (rtc_shared_library is not one of them). So which ones can/should I modify to build the shared library then?

To give you some context, the only reason I want to do this is because my project links dynamically to the C runtime library (CRT), and so when i try to link my project to webrtc, i get linker errors (because the static webrtc lib links statically against CRT)... and my project has a lot of dependencies, so rather than re-build each dependency & the project to link against CRT in the same way that webrtc does, it makes more sense for me to build webrtc to link in the way that my project and it's dependencies do ...

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/af457018-362f-4a34-ab8f-58f85597475a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nikolay Baklicharov]

Hello,

Building webrtc as a shared library is very hard and time consuming, because Google does not officially support that. However you pain with the static vs dynamic CRT can be resolved very easy.

Just before going in the step to generate the build files by using "gn gen", open the file: "src\build\config\win\BUILD.gn" and find the following code around line 404:

# Desktop Windows: static CRT.
      configs = [ ":static_crt" ]

and change the ":static_crt" to ":dynamic_crt", then go as usual and do "gn gen" with "ninja -C". The webrtc will be built again as a static library but it will be linked to the dynamic CRT and you will have no more issues with that. :)

[Alexandre GOUAILLARD]

hi nikolay,

"Building webrtc as a shared library is very hard and time consuming, because Google does not officially support that"

That's an interesting opinion you're sharing.

With google (mirko bonadei), we put back shared library support in chrome in october 2018.

The public ticket is here for details:

https://bugs.chromium.org/p/webrtc/issues/detail?id=9419

This patch added a gn arg to control the build:

https://webrtc-review.googlesource.com/c/src/+/104980

The only thing you have to do is to ask for component build and use rtc_enable_symbol_export in the command line, without any code modification.

Please note that the choice about which symbols are being exposed and which are not is done with respect of chrome usage, and NOT with respect to the public API. In the world of google:

"

This [...] uses RTC_EXPORT (defined in rtc_base/system/rtc_export.h)
to mark WebRTC symbols as visible from a shared library, this doesn't
mean these symbols are part of the public API (please continue to refer
to [1] for info about what is considered public WebRTC API).
[1] - https://webrtc.googlesource.com/src/+/HEAD/native-api.md

"

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/69a31c0e-3b17-4b88-b28d-6f6f11de4276%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nikolay Baklicharov]

Hey Alex,

The last time i did a research about that was on version 69. It seems that I've missed the cool feature with about a month.

However... Such vital information could be added to https://webrtc.org/native-code/development/

The biggest issue with libWebRTC is missing information and major refactoring even to the "public" APIs. For example when I upgraded to version 72, not only I had to rewrite my code that was using cricket::VideoCapturer. but I also had linker issues under VC++, because someone decided to disable the iterator debugging(enable_iterator_debugging) option by default for debug builds and because the docs were not updated I had to do a research again to find out whats wrong(the linker warnings)...

Also I had issues with clang(which is used by default to build the library) which generated invalid .lib files that VC++ can't consume. This is fixed by setting use_lld to false and by disabling clang generally.

I get it that all changes are published and discussed here in this group, but it's hard to keep up with all of it, especially if you are not devoted to WebRTC.

Sorry, this was a bit of pain that I felt like sharing, nothing personal. Keep up with the good work. :)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/69a31c0e-3b17-4b88-b28d-6f6f11de4276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nikolay Baklicharov]

This is fixed by setting use_lld to false *or* by disabling clang generally.

-- Fixed a little mistake...

[Alexandre GOUAILLARD]

liwebrtc is big, it takes time to understand enough to write all the missing doc.

some people have already written about that:

https://www.callstats.io/blog/2018/04/11/top-in-depth-resources-for-keeping-up-to-date-on-webrtc

https://www.callstats.io/blog/2018/06/04/4-highly-recommended-ways-to-learn-webrtc

people who know those details don't need to write about it anymore, and more often than not do not have the luxury to spend the time writing the missing doc for free.

Would a dedicated book or resource about webrtc.org code help? 

Would you be, for example, ready to pay for such book to happen?

Shall we start a crowdfunding of some sort?

Regards,

Dr. Alex.

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/32a2efff-03fb-4939-beb0-5a5f1ac4d7b5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nikolay Baklicharov]

Sure I would pay. The time I've lost in roaming around the code is much more expensive than a book would be.

The web side(JS and HTML) is well covered from various of sources. I would like to have better docs on the Native side and I would pay for that, so feel free to start crowdfunding and/or anything else that would help. I'm in! :)

Regards,

Nik.

неделя, 30 юни 2019 г., 19:14:17 UTC+3, Alexandre GOUAILLARD написа:

liwebrtc is big, it takes time to understand enough to write all the missing doc.

some people have already written about that:

https://www.callstats.io/blog/2018/04/11/top-in-depth-resources-for-keeping-up-to-date-on-webrtc

https://www.callstats.io/blog/2018/06/04/4-highly-recommended-ways-to-learn-webrtc

people who know those details don't need to write about it anymore, and more often than not do not have the luxury to spend the time writing the missing doc for free.

Would a dedicated book or resource about webrtc.org code help? 

Would you be, for example, ready to pay for such book to happen?

Shall we start a crowdfunding of some sort?

Regards,

Dr. Alex.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/32a2efff-03fb-4939-beb0-5a5f1ac4d7b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sean DuBois]

Nik,

(NB I am biased I work on Pion WebRTC) 

Is it really worth investing more time in libwebrtc? The interests of its owners don't line up with yours, it is going to be a constant battle to make things work. You can fix things, but eventually it will slide back. 

There are multiple WebRTC implementations out there. I would love to see one owned by the greater community thrive, then we won't these kinds of issues.

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/58e310c7-7c27-4744-8d70-7d7b0547ed6c%40googlegroups.com.

[Alexandre GOUAILLARD]

Sean,

In the interest of those who end up on this thread, could you kindly list the multiple webrtc implémentations out there?

Regards

Dr alex.

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bb7xQu06W3O35%2BipWaEeQpcB41eDSm_5dRatLq6%2BtKuZA0_7Q%40mail.gmail.com.

[Sean DuBois]

Yea! I will leave Pion at the end (and my goals when building it) if the authors of other things are around would love to hear their motivations

https://github.com/aiortc/aiortc

* Python implementation, supports media and Datachannels

https://gstreamer.freedesktop.org/documentation/webrtc/index.html

* GStreamer implementation, supports media and Datachannels

https://github.com/nodertc

* Javascript implementation. Not complete yet, but most of the hard problems have been solved!

https://github.com/rawrtc/rawrtc

* C++ implementation. Very easy to build/portable. Also has a 'Datachannels only' lib that can be used.

https://github.com/pion/webrtc 

* 100% clean room rewrite in Go, uses no C libraries / no memory safety issues.

* Supports media and DataChannels (QUIC and SCTP)

* Compiles to C. I call it from C programs, I just generate a `.so` and `.h`

* Uses the WebRTC API. If you know how to use Javascript API, you know how to use Pion.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/B56DBE61-0D43-4620-8ABB-7F80ACA574D3%40gmail.com.

[Kunal Jathal]

Nikolay,

Wow thanks a lot for your answer -- it's crazy, I did not notice your message till now, but I actually ended up doing the exact same thing as you described i.e. I changed 

configs = [ ":static_crt" ]

to ":dynamic_crt" in src\build\config\win\BUILD.gn. And yes, I also was hitting the iterator_debug error! I also had to re-enable it (in src\build\config\BUILD.gn) in order to resolve my linker errors!! In addition to those 2 changes, I also added rtc_json to the list of dependencies of the static library rtc_base in src/rtc_base/BUILD.gn in order to fix some json linker errors I was getting.

After making these 3 changes, I was finally able to build a working webrtc.lib that seems to work.

Alex,

I initially tried using is_component_build=true, but I got an assertion which prevented me from building (seems to be consistent with what is described here). It also seems to be mentioned that the work is still not complete and hence the assertion cannot be removed. So I guess my questions are,

1) Can I / should I remove the assertion locally and set rtc_enable_symbol_export=true as you mention? And I guess, more importantly

2) Is there any difference between doing it this way, vs. the way I did it ? (i.e. setting configs = [ ":dynamic_crt" ] in src\build\config\win\BUILD.gn.

Please let me know, thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/58e310c7-7c27-4744-8d70-7d7b0547ed6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bb7xQu06W3O35%2BipWaEeQpcB41eDSm_5dRatLq6%2BtKuZA0_7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

---
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...@googlegroups.com.

[Nikolay Baklicharov]

Yeah, next time you can save some time to yourself by following replies your questions. :)

@Alex Just FYI, the thing you've suggested with "rtc_enable_symbol_export" is broken. Tons of errors arise from exported classes with forgotten deletion of copy constructor/assignment operator.

@Sean Thanks for your sharing. Unfortunately I don't use Go and the other alternatives you've shared seems to have missing functionalities. I don't like libWebrtc at all, but for now it's the only options for me...

[Alexandre GOUAILLARD]

Nikolay,

I agree dealing with libwebrtc sucks: actually .. it's pretty documented since at least 2015:

https://webrtchacks.com/building-webrtc-from-source/

You are right, it seems that the original goal of re-enabling DLL build was not completely fulfilled, at least not for the default build of stand-alone webrtc.

You can see my original push to google in march 2017 and there after:

https://bugs.chromium.org/p/webrtc/issues/detail?id=7368

One of the reason they moved from GYP to GN was also to be able to remove circular dependencies. Those are not so much a problem for static lib, but are for shared libs. This was only resolved, especially for the audio targets early 2018:

https://bugs.chromium.org/p/webrtc/issues/detail?id=7369

Alas, Henrik K. the only QA of the stockholm team left, and it took some time to bring new guys in. I did not give up.

This at least allowed to make an apple framework on mac equivalent to the iOS one, and enable appRTCDemo on mac, so they were some good side effect.

The RTC_EXPORT solution was then implemented by mirko and added, which is IMHO the right approach to handle windows specific dll_import / dll_export switches. I was left with the impression it was finalised. We maintain a shared lib build internally, but we have a ... "derivated" build systems with an extra step between GN and NINJA which allows us a little bit more flexibility than GN does.

The current status seems to be: no dll unless you re a chrome build, until someone makes a patch.

My bad for bringing you on the wrong path and wasting some of your time.

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/0a3332f3-9ec7-4a15-99aa-48bacbb740c0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alexandre GOUAILLARD]

there is an opportunity to show your interest in making this happen.

Please go ahead and "star" or comment in the following ticket:

https://bugs.chromium.org/p/webrtc/issues/detail?id=7369

[Nikolay Baklicharov]

Did my part. I hope to see this happen sooner.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/0a3332f3-9ec7-4a15-99aa-48bacbb740c0%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

• 
  

[Fang Yu]

I am trying to export symbols in webrtc.lib on Windows. I think I am running into the same error mentioned previously: `with "rtc_enable_symbol_export" is broken. Tons of errors arise from exported classes with forgotten deletion of copy constructor/assignment operator.`

With just `is_debug = false`, ninja builds fine, but when I try to link it into a desktop app using CMakeLists.txt and build in Visual Studio I got many unresolved external symbol errors, e.g, `error LNK2019: unresolved external symbol "public: __cdecl webrtc::PeerConnectionInterface::IceServer::IceServer(void)"`

So I am trying to build webrtc.lib using `rtc_enable_symbol_export = true`, but ninja fails now with error, e.g.,

../../buildtools/third_party/libc++/trunk/include\memory(2528,3): note: copy constructor is implicitly deleted because 'unique_ptr<const webrtc::RTCStats, std::__1::default_delete<const webrtc::RTCStats>>' has a user-declared move constructor

  unique_ptr(unique_ptr&& __u) _NOEXCEPT

  ^

Does anyone know a solution to this?

Thanks a lot!