Switching to GN from GYP: RTTI flag and static libraries?

[Christoph K]

Hi,

I used to build webrtc with RTTI using the old GYP by editing the common.gypi file. Afterward the build I used the generated thin .a files to get the needed object files and merged it all into one big archive to use as a static library in external projects. Switching to GN I ran into some problems.

How can I set the RTTI flag? I assume the common.gypi file isn't in use anymore?

Is there a good way to create a static library containing all objects (not a thin archive)?

Thanks 

Christoph

[Akshay Shah]

Any update on this? Were you able to get .a files for webrtc using GN?

[jan.ema...@gmail.com]

Hi,

About the .a file maybe this helps https://groups.google.com/forum/#!searchin/discuss-webrtc/android$20static$20libraries%7Csort:relevance/discuss-webrtc/W5P7Glao2fs/DKA2MSp8AQAJ

For the RTTI we have the same problem and until now we are not able to change to a RTTI build.

[Akshay Shah]

Hi,

Thanks for your reply.

I did went through that list but I didnt understand exactly the complete changes required.

Would be nice if you could elaborate more on all the required changes and if possible, provide complete changes of rtc_static_library and deps.

[jan.ema...@gmail.com]

Hi

As far as I remember this is the only change I made. I can send the BUILD.gn but that can differ per commit. So I would advice make the above change to your BUILD.gn. This for generating the libjingle_peerconnection.a. For us this is enough. If you need more libs than you have to do that the same way but we didn't do that.

Here the git diff of the BUILD.gn.

index b7cd679..a0f7e86 100644
--- a/webrtc/api/BUILD.gn
+++ b/webrtc/api/BUILD.gn
@@ -43,7 +43,8 @@ config("libjingle_peerconnection_warnings_config") {
   }
 }

-rtc_source_set("libjingle_peerconnection") {
+rtc_static_library("libjingle_peerconnection") {
+  complete_static_lib = true
   cflags = []
   sources = [
     "audiotrack.cc",
@@ -129,6 +130,9 @@ rtc_source_set("libjingle_peerconnection") {
     "../media",
     "../pc",
     "../stats",
+    "../system_wrappers:field_trial_default",
+
+    "../system_wrappers:metrics_default"
   ]

   if (rtc_use_quic) {

B.t.w. We now have linker errors generating the .so. Probably because of the addition +    "../system_wrappers:field_trial_default" but we don't care for now because we have enough with the .a for now. 

[Henrik Kjellander]

I'm interested in helping out with this (but I'm still learning myself).

I think https://crrev.com/b62dbbe985c643cf4ee28e4c73c75bb3ef5e4d54 should solve some of this, making most targets a static_library (as in GYP). 

Does it help to add the //build/config/compiler:rtti config to libjingle_peerconnection? 

For bundling everything into a large library, you could also look at the complete_static_lib property.

Please let us know your findings, and provide more details on your use case (preferably with command lines demonstrating what's missing).

[Henrik Kjellander]

Also, notice that RTTI is forbidden in the Google C++ style guide and unlikely something we'll ever support.

[Niels Moller]

On Tue, Sep 27, 2016 at 8:26 AM, Henrik Kjellander <kjell...@webrtc.org> wrote:

> Also, notice that RTTI is forbidden in the Google C++ style guide and

> unlikely something we'll ever support.

But not using rtti *within* webrtc (i.e., not using dynamic_cast or any other features requiring rtti info in the generated code) is a different issue than enabling building webrtc with rtti support, to help *other* applications which do use rtti, and also want to use webrtc.

I don't understand all the fine details of rtti in object files, but I think it's preferable to have all object files linked into an executable be compiled with the same rtti-related options, so it would make the most sense as a top-level build option.

And similar considerations apply to building with support for exceptions and stack unwind magic, I imagine.

/Niels

[Fredrik Solenberg]

+1

[Alexandre GOUAILLARD]

+1

It was supported in the GYP build, and used by some projects out there.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6c177737-0e5c-4b9a-b6b0-8a9f09fc1ffd%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

• 
  

[jan.ema...@gmail.com]

We tried to build webrtc with rtti option by adding (or changing) it in some libraries. But we run into a lot of dependencies with used no-rtti. So at the end we couldn't build the webrtc with rtti. In our own lib we use rtti so we had/have a serious problem in using webrtc.