Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Issues Compiling on Windows 10 #46

Closed
shadoxx opened this issue Oct 1, 2018 · 20 comments
Closed

Issues Compiling on Windows 10 #46

shadoxx opened this issue Oct 1, 2018 · 20 comments
Assignees
@Ben-cos
Labels
help wanted question
Milestone
18-11

Comments

@shadoxx
Copy link

shadoxx commented Oct 1, 2018

I'm using Windows 10 with Visual Studio Community 2017, attempting to compile OBS w/webrtc and it doesn't seem to be working.

What's the current recommended way of compiling and linking the external libwebrtc library on Windows 10? Thank you!
@agouaillard-cosmo agouaillard-cosmo self-assigned this Oct 2, 2018
@agouaillard-cosmo agouaillard-cosmo added this to To do in Generic WebRTC Support via automation Oct 2, 2018
@agouaillard-cosmo
Copy link
Contributor

Dear shadoxx,
thank you for your feedback.

  1. Please note that the maintainers of this repository are all based in Singapore, and all volunteering their time. If you place a ticket at 4am local time, you will have to wait a little bit to get an answer.

  2. Generally speaking, you should wait a little bit to get an answer to your questions, before you jump to any conclusion. This ticket was open only 4 hours ago.

  3. The current recommended way of compiling libwebrtc is documented on the libwebrtc website. More specifically: https://webrtc.org/native-code/development/prerequisite-sw/
    Note that the recommended version of MSVC is older that the one you would download today, but we can confirm that the latest one works.

  4. OpenSSL build of libwebrtc might not be needed, and the flags are already in place in google's code to that build. More specifically, if you look at the source code, you will see the ssl flags which needs to be passed to the GN GEN command that allow to use an external SSL library, if you need to (line 43):
    https://webrtc.googlesource.com/src/+/master/rtc_base/BUILD.gn

  5. You do NOT depend on any package we might provide. However, compilation of libwebrtc is an under documented process with strong ties to dark magic. From time to time, when people ask nicely, we compile it for them to make their life easier. If you think the compilation of the code from webrtc.org is too difficult, and depending projects are NOT easily reproducible, please let Google know, Their bug tracker is there:
    https://bugs.chromium.org/p/webrtc/issues/list

  6. README has been updated accordingly.

@agouaillard-cosmo agouaillard-cosmo mentioned this issue Oct 2, 2018
Closed
@agouaillard-cosmo agouaillard-cosmo added this to the October Sprint milestone Oct 2, 2018
@agouaillard-cosmo
Copy link
Contributor

I opened a new bug to try to make it easier on our side. It will not alleviate the pain of recompiling libwebrtc though, for which we do not claim any responsibility. #47
Let me know if this sounds reasonable to you, and I'll close this bug.

@shadoxx
Copy link
Author

shadoxx commented Oct 2, 2018 •
edited
Loading

Sorry @agouaillard-cosmo, I was in a state of sleep deprivation and frustration when I made this issue. I have removed my unkind posts and accusations as they don't reflect my generally cheery demeanor.

Thank you for the links and updated README. I will be attempting to compile libwebrtc from source this week. I agree that this is black magic, and my initial frustration stemmed from dead links and bad autocompiler scripts floating around the web. This whole experience has driven me to create my own build process.

Again, thank you for the work that you do.

@agouaillard-cosmo
Copy link
Contributor

No problem, We've all been seriously frustrated by libwebrtc build system. And we still are, as even when it works it is really, really Slow ...... First webrtc compilation is a two days effort, time to get the environment right, and subsequent compilations can take 8 hours, including several hours to get teh source code. With different optimisations, we are down to an hour, but it s still not fast enough to do it on a commit basis ... Frustrating.

https://my.cdash.org/index.php?project=libwebRTC&date=2018-09-26

I strongly recommend that you ask your questions about libwebrtc compilations on the webrtc-discuss mailing list. I also read that list, and will answer there if you're stuck, but it will benefit the bigger community.

Any question specifically about OBS-studio-webrtc should be asked here though.

@agouaillard-cosmo agouaillard-cosmo removed this from the October Sprint milestone Oct 3, 2018
@shadoxx
Copy link
Author

shadoxx commented Oct 4, 2018 •
edited
Loading

OK, I have compiled libwebrtc from source (thanks for the links!).

I have the webrtc.lib file in my src/out/Release/obj/ directory. What now? There's a variable in the CMake process libwebrtc_DIR. What's the recommended way of specifying this variable? I've tried pointing it at the out directory with the compiled output, but it complains about a missing CMake file?

EDIT: I've found the relevant options in the CMakeLists.txt file. I'll make the relevant modifications and report back.

@agouaillard
Copy link
Contributor

yeah ...... When you get use to the simplicity of our installer, it's hard to get back. Everything is done on the installer side so that you can just use "find_package(libwebrtc)" in your cmake code and it just works(TM).

OK, i'm doing that from memory, but that should get you there. Beware, pain ahead. Make sure you are using branch_head 65.

  1. comment out the find_package line in the cmakelists.txt
  2. Deal with libs
    a. in the OBS cmakelist: set( WEBRTC_LIBRARIES "webrtc;rtc_json;jsoncpp" )
    replacing webrtc, rtc_json, and jsoncpp by the location (full path) of the respective libs
    b. if I remember correctly, rtc_json and jsoncpp are compiled only for the
    examples in libwebrtc, and are embedded in the examples. I.E. by default there is no corresponding .lib. You might have to recompile them as a library by replacing their target definition in the corresponding GN from rtc_source_set to rtc_static_lib
  3. deals with includes
    in the OBS cmakelist:
    • include_directories( ) with the path to the webrtc/src dir
    • include_directories( ) with the path to the webrtc/src/third_party dir
    • libyen might be needed too
  4. deals with extra definitions:
    add WEBRTC_WIN to your compiler's project definition

good luck.

@shadoxx
Copy link
Author

shadoxx commented Oct 4, 2018 •
edited
Loading

Didn't know about the examples producing the rtc_json.lib and jsoncpp.lib artifacts, thanks for the tip! rtc_json.lib specifically has been where I've been stuck today. I've heavily edited CMakeLists.txt and some other files, and it's 99% compiled!

I've been able to mostly reproduce what I believe is in the installers you provide, including the cmake and include directories. I won't release these as a public bundles, but I did find the CMake files you've written other places on the web from talks and demos you've given. They have been immensely helpful! After spending a week on this already I can see why you have kept your build process proprietary. It's a lot of work.

@agouaillard
Copy link
Contributor

The work on those scripts has started in 2012 .... I wrote some blog posts about it around 2015:
http://webrtcbydralex.com/index.php/2015/07/22/automating-libwebrtc-build-with-cmake/

it's a race game, we need to be able to shield ourselves from google non-backward compatible 200 commits a week .....

We're not releasing the bundle because it s a lot of work, we're not releasing the bundle because they are not stable enough yet. We need them to be stable enough, so that if we release them to the public, the amount of maintenance will be tolerable. You only work on windows, but we support win, linux, mac, android, iOS, all the way since revision 62 up to 69.

We not only build libwebrtc, but we import all the google unit tests for it, run them, check that they pass, and add some tests on our own to make sure it works. Basically the projects that depend on libwebrtc should be able to use the pre-compiled libs without a doubt.

We also want people to be able to upgrade their libwebrtc version without too much trouble, which is absolutely not the case today. So we still have some work to do.

think about a world without depot_tools, without hours-long fetch and sync, without GN, ninja, ...... where you find_package( libwebrtc 65 ) and it just works. Webrtc finally made easy.

@shadoxx
Copy link
Author

shadoxx commented Oct 4, 2018

it's a race game, we need to be able to shield ourselves from google non-backward compatible 200 commits a week .....

That's a lot of commits.

We're not releasing the bundle because it's a lot of work, we're not releasing the bundle because they are not stable enough yet. We need them to be stable enough, so that if we release them to the public, the amount of maintenance will be tolerable.

That makes loads more sense. Thanks for the clarification.

You only work on windows, but we support win, linux, mac, android, iOS, all the way since revision 62 up to 69.

Fair enough, as this topic covers Windows, but my day job involves design and implementation of build/delivery pipelines on Linux. After I have accomplished getting the Windows side of things handled, I will be duplicating my work on Linux. I will be targeting Fedora and Ubuntu.

think about a world without depot_tools, without hours-long fetch and sync, without GN, ninja, ...... where you find_package( libwebrtc 65 ) and it just works. Webrtc finally made easy.

This is actually what got me interested in the whole ordeal. I believe webrtc enables the next generation of interactivity for humanity as a whole, and I've put together the demos and SEEN what the future can be. I've explored the tech and I'm blown away for the potential that it adds to existing stacks. As someone I know put it, it's like the whole Internet gets an upgrade!
However, the tooling right now requires lots of specialized knowledge that can be difficult to learn if you don't know where to get started. That's currently my crusade.

...This may have gone a bit off topic. In any case, I was able to successfully reproduce and link against rtc_json.lib thanks to your guidance! I'm sure I have a lot more to learn, but you have been patient and helpful and I will be contributing more in the future! Thank you again @agouaillard-cosmo!

@ChrisVifzack
Copy link

Hello and thank you for all the great input! This conversation actually has helped me a lot so far.
I managed to build branch-head/65 and generated rtc_json.lib, jsoncpp.lib and webrtc.lib following the description of @agouaillard.
Then I made the changes in the CMakeLists files and was able to generate the VS solution. (using VS 2017 15.8.7). When trying to build the solution for Debug x64, I got 34 succeeded and 5 failed project builds. The 5 failing projects are:

  1. websocketclient.vcxproj (complains about missing include files Asio and OpenSSL. Any ideas why?)
  2. obs-scripting.vcxproj
  3. obs-outputs.vcxproj
  4. _obspython.vcxproj
  5. obs.vcxproj

So, I went to the project settings of those 5 projects, added WEBRTC_WIN as preprocessor definition and rebuild the solution. Unfortunately, they still fail. This is where I currently stand.

I will continue to figure out what the problem is. Any help is welcome.
@shadoxx did it build for you? If it did, maybe I made a mistake in the CMakeLists (full disclosure, I am not really familiar with cmake)

@agouaillard-cosmo
Copy link
Contributor

What's the full error log ?

@ChrisVifzack
Copy link

This: output-log.txt

@agouaillard-cosmo
Copy link
Contributor

grep error ~/Downloads/output-log.txt

8>d:\videostreaming\obs-studio-webrtc.git\tags\2.4\plugins\websocket-client\websocketpp\common\asio.hpp(46): fatal error C1083: Cannot open include file: 'asio/version.hpp': No such file or directory

Are you sure you did a recursive clone, it looks like some submodule are not initialised.
If your /plugin/websocket/thirdparty/asio folder ris empty, you did not clone the submodules.

8>d:\videostreaming\obs-studio-webrtc.git\tags\2.4\plugins\websocket-client\websocketclient.cpp(2): fatal error C1083: Cannot open include file: 'openssl/opensslv.h': No such file or directory

You need an openssl install. Even better, build libwebrtc with openssl support, and it will be provided for free. Otherwise, cmake ALWAYS come with the FindOpenSLL.cmake script, so you can add:
find_package( OpenSSL )
in your file and use it. This is what I should do anyway, to fix bug #20

23>d:\chromium-webrtc\src\rtc_base\timeutils.h(133): error C2614: 'rtc::IntervalRange': illegal member initialization: 'min_' is not a base or member
23>d:\chromium-webrtc\src\rtc_base\timeutils.h(133): error C2614: 'rtc::IntervalRange': illegal member initialization: 'max_' is not a base or member

I think you need to define NOMINMAX

23>d:\videostreaming\obs-studio-webrtc.git\tags\2.4\plugins\obs-outputs\webrtcstream.cpp(5): fatal error C1083: Cannot open include file: 'libyuv.h': No such file or directory

you need to add the path to libyuv.h to your include paths. It should be something like that:
webrtc/src/third_party/libyuv/

25>d:\videostreaming\obs-studio-webrtc.git\tags\2.4\ui\window-basic-status-bar.cpp(26): error C2065: 'WEBRTC_MAJOR_VERSION': undeclared identifier

Just define it to whatever version you use, it does not really matter anyway.

@ChrisVifzack
Copy link

ChrisVifzack commented Oct 18, 2018 •
edited
Loading

Thanks for your reply!

Oh my... checking out not recursively gets me once again... thanks! I made a new clone and made sure to use --recursive.
Another issue was that I didn't have the correct Python version. I was on Python 2.7 and now, after installing Python 3.6, I am down to 3 failing projects.

I am facing several mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug errors. Is there anything I can do about that? (I just read aisouard/libwebrtc#39 and now I feel quite stuck...)

@agouaillard-cosmo
Copy link
Contributor

  • well .... welcome to windows DLL hell.
  • Actually VS 2015: how to change /MD, /MT flags aisouard/libwebrtc#39 is not up-to-date anymore. I eventually found the time to help google resurrect the DLL build for windows, so theoretically you are able to have everything compiled with MD (see this commit a few weeks back). But it s not documented, and it s really not recommended yet.
  • you should be able to link the obs-outputs plugin (which MUST be a dll) against the static libwebrtc.

in axel scripts, it s hardcoded on line 87 to 90 of this file

note that you can find some of your missing definitions on line 91 of the same file.

at this stage, you should realise that this is a never ending laundry list, and this is unmaintainable as is.

@agouaillard-cosmo
Copy link
Contributor

by the way, if you installed depot_tools correctly, you should have python from depot_tool in the path.

@ChrisVifzack
Copy link

well .... welcome to windows DLL hell.

Yeah... it is really messy and the frustration is definitely there... but I don't want to give up on this just yet!

So... the lines 87 to 90 in this script... how am I supposed to use them? Is there any file I can copy that to? Like CMakeList.txt in obs-outputs? Or do I have to start from Axel's repository and build the libwebrtc entirely with cmake instead of ninja? (sorry, for this naive question, but this whole cmake and ninja stuff is quite new for me)

@ChrisVifzack
Copy link

ChrisVifzack commented Oct 18, 2018 •
edited
Loading

Oooook, so adding those commands to the cmakelists of obs-outputs and websocketclient actually did something... now I got new error messages...
Could you give me some advice once more? Here is the output: output-log-2.txt

EDIT:
I could resolve the OpenSSL related error messages and now I received this: output-log-3.txt

@agouaillard
Copy link
Contributor

agouaillard commented Oct 18, 2018 via email

@ChrisVifzack
Copy link

Yeah, ok. I guess there is no way around this. Thank you for the references and your time.

@agouaillard-cosmo agouaillard-cosmo added this to the November Sprint milestone Nov 2, 2018
Generic WebRTC Support automation moved this from To do to Done Dec 5, 2018
@CoSMoSoftware CoSMoSoftware locked and limited conversation to collaborators Dec 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@Ben-cos Ben-cos

Labels
help wanted question
Projects
None yet
Milestone
18-11
Development

No branches or pull requests
5 participants
@agouaillard @shadoxx @ChrisVifzack @agouaillard-cosmo @Ben-cos