Pull in vldevl's changes for linux building. #12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR brings the following fixes and changes: - In run.py, fetch a depot_tools version which matches the release date of the WebRTC SDK release we are using (and pin this depot_tools version so that it does not get automatically and spuriously updated by the build system). This ensures that the build will not fail and will use the appropriate parameters (e.g. compiler and linker options) for this particular release. This also makes it possible to build this release "indefinitely" (even in a few months or years) and with these changes backported to m114, it would be possible to build the latter today (tested by me on x86_64 and arm64 Linux systems). Note that a new WEBRTC_LAST_COMMIT_DATE entry has also been added to the VERSION file to hold this date. - In run.py, ensure that the depot_tools Python3 venv is properly bootstrapped (else, the build may fail, depending on what Python3 modules are installed or not on the host system). - In run.py, ensure that 'ranlib' is called to create an index of the native object modules, since (quoted from llvm-ar documentation): "Unlike other implementations of ranlib, llvm-ranlib indexes LLVM bitcode files, not native object modules". This way the Linux WebRTC static library can be successfully linked to a shared library using GNU ld. - 'disable_crel.patch' got added to solve the problem caused by the use of a LLVM linker's idiosyncrasie, making it impossible to link the Linux library with GNU ld. - 'gcc_fpermissive_error.patch' got added to solve compilation failures when building a Linux viewer with gcc, due to a -fpermissive/-Wchanges-meaning error in the WebRTC SDK headers themselves. - Several changes done to run.py so to allow building the library on ARM64 (arm_v8) Linux hosts. Note however that the said hosts will still need an x86_64 emulator installed (e.g. box64) because even though I did add "host_cpu=arm64" to the build parameters, the WebRTC SDK build system still uses an x86_64 LLVM toolset to build on arm64 !!! o.O So far, and while m114 builds just fine with the same method, I could not get m137 to build on my ARM64 SBC due to a double-free() error at link time in box64/lld...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From VLDevl:
This PR brings the following fixes and changes:
In run.py, fetch a depot_tools version which matches the release date of the WebRTC SDK release we are using (and pin this depot_tools version so that it does not get automatically and spuriously updated by the build system). This ensures that the build will not fail and will use the appropriate parameters (e.g. compiler and linker options) for this particular release. This also makes it possible to build this release "indefinitely" (even in a few months or years) and with these changes backported to m114, it would be possible to build the latter today (tested by me on x86_64 and arm64 Linux systems). Note that a new WEBRTC_LAST_COMMIT_DATE entry has also been added to the VERSION file to hold this date.
In run.py, ensure that the depot_tools Python3 venv is properly bootstrapped (else, the build may fail, depending on what Python3 modules are installed or not on the host system).
In run.py, ensure that 'ranlib' is called to create an index of the native object modules, since (quoted from llvm-ar documentation): "Unlike other implementations of ranlib, llvm-ranlib indexes LLVM bitcode files, not native object modules". This way the Linux WebRTC static library can be successfully linked to a shared library using GNU ld.
'disable_crel.patch' got added to solve the problem caused by the use of a LLVM linker's idiosyncrasie, making it impossible to link the Linux library with GNU ld.
'gcc_fpermissive_error.patch' got added to solve compilation failures when building a Linux viewer with gcc, due to a -fpermissive/-Wchanges-meaning error in the WebRTC SDK headers themselves.
Several changes done to run.py so to allow building the library on ARM64 (arm_v8) Linux hosts. Note however that the said hosts will still need an x86_64 emulator installed (e.g. box64) because even though I did add "host_cpu=arm64" to the build parameters, the WebRTC SDK build system still uses an x86_64 LLVM toolset to build on arm64 !!! o.O So far, and while m114 builds just fine with the same method, I could not get m137 to build on my ARM64 SBC due to a double-free() error at link time in box64/lld...