[SOLVED] Problem compiling WebRTC and boost::uuid due to X509 redefinition problem. Where should I create issue?

Problem compiling WebRTC and boost::uuid due to X509 redefinition problem. Where should I create issue?

I'm experimenting with WebRTC and stumbled upon annoying problem. While using both:

BoringSSL(which is third_party for WebRTC) and boost::uuid I cannot compile my solution due to X509 redefinition problem.

Problem:

BoringSSL define X509 by its own so when I link wincrypt.h via boost::uuid which defines it by itself, redefinition problem occurs. This problem will occur every time you will try to use wincrypt.h or any other third_party that depends on it along with WebRTC.

Solution:

I may use something other than boost::uuid
I can add in BoringSSL file base.h, #undef preproccessor macros:

#ifdef CRYPT
    #undef X509_NAME
    #undef X509_CERT_PAIR
    #undef X509_EXTENSIONS
#endif

That way you can use in your project's CMake

add_definitions(-DCRYPT)

and problem will be instantly solved. Flag name is irrelevant, just example.

My second solution is preferable and I would like it to be included into further versions of BoringSSL for WebRTC. On BoringSSL website there is an information which state:

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.

My questions:

Does that quote means that with WebRTC somehow unique version of BoringSSL is shipped?

If so, where should I direct my issue? I would like to contribute so it would help someone else in the future but I am not sure where, to WebRTC repo? To BoringSSL?

Thanks in advance for clearing it out for me.

Solution

Boost.Asio relies on OpenSSL library. It should not be a surprise that OpenSSL and BoringSSL are not compatible. Putting the #ifdef CRYPT plaster that you propose may actually put much more serious incompatibility issues under the carpet. I believe that the right way would be to compile WebRTC with OpenSSL, or use BoringSSL for all your project, just like nghttp2 did it.