We never produced static release executables on Linux before, but the dynamic libraries they depended on were universal enough that nobody noticed. Now that we have released v2.5 and switched to GitHub Actions for CI builds, the Linux executables depend on libatomic, which is causing issues for some users.
Although we can't create fully-static executables on macOS or Windows, we can at least do so on Linux.
This adds a GYP variable static_link_binaries which can be set to request full-static binaries on Linux. This also exposes the Chromium build variable disable_fatal_linker_warnings, which is necessary when static linking on Linux due to static-link-related warnings generated by libcurl for its use of getaddrinfo. Finally, this enforces the definition of __UCLIBC__ with static linking on Linux, which is the only way to disable malloc hooks in Chromium base. Those hooks cause linker failures when linking statically on Linux.
A new check has been added to the release workflow to ensure that the builds we create are statically linked on Linux.
Closes#965
This brings our default build config more in line with what is
necessary for some platforms anyway: using the system-installed
toolchain and sysroot to build everything.
We will no longer fetch source or binaries for any specific build
tools, such as libc++, clang, gold, binutils, or valgrind.
The main part of this change is the changing of default gyp settings
in gyp_packager.py. For this, a bug in gyp_packager.py had to be
fixed, in which similar GYP_DEFINE key names (such as clang and
host_clang) would conflict, causing some defaults not to be installed
properly.
In order to enable clang=0 by default, some changes had to be made in
common.gypi:
- compiler macros added to fix a compatibility issue between
Chromium's base/mac/ folder and the actual OSX SDK
- replaced clang_warning_flags variables with standard cflags
settings, plus xcode_settings for OSX
- turned off warnings-as-errors for non-shaka code, rather than
allow-listing specific warning types, since we can't actually fix
those warnings on any platform
- disabled two specific warnings in shaka code, both of which are
caused by headers from our non-shaka dependencies
Also, one warning (missing "override" keyword) has been fixed in
vod_media_info_dump_muxer_listener.h.
Although these changes were done to make building simpler on a wider
array of platforms (arm64, for example), it seems to make the build a
bit faster, too. For me, at least, on my main Linux workstation:
- "gclient sync" now runs 20-30% faster
- "ninja -C out/Release" now runs 5-13% faster
The following environment variables are no longer required:
- DEPOT_TOOLS_WIN_TOOLCHAIN
- MACOSX_DEPLOYMENT_TARGET
Documentation, Dockerfiles, and GitHub Actions workflows have been
updated to reflect this.
The following GYP_DEFINES are no longer required for anyone:
- clang=0
- host_clang=0
- clang_xcode=1
- use_allocator=none
- use_experimental_allocator_shim=0
Documentation, Dockerfiles, and GitHub Actions workflows have been
updated to reflect this.
The following repos are no longer dependencies in gclient:
- binutils
- clang
- gold
- libc++
- libc++abi
- valgrind
The following gclient hooks have been removed:
- clang
- mac_toolchain
- sysroot
Change-Id: Ie94ccbeec722ab73c291cb7df897d20761a09a70
In e2efb5d4, I fixed shared_library builds on Windows, but I
introduced another issue in which the libpackager_type variable was
not correctly defined by default. This meant that the build only
worked with this variable explicitly-defined in GYP_DEFINES when
gclient sync was run.
This fixes the default definition so that libpackager_type does not
need to be defined explicity.
Related to #318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: If353e1d3c312ab0c568d4d4d2b789e922d7216e1
Shared library builds worked, but failed tests because they were made
with the wrong CRT linker settings. Strings allocated within the
library could not be freed outside the library because the dynamic CRT
was not used.
This sets necessary gyp variables to link with a dynamic CRT on
Windows, thereby fixing tests running in shared library mode that
otherwise hung in a GitHub Actions environment.
Related to #318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: Iffefd27c2aa4ec479ce1d10b099483e417d2231f
To make shared_library builds work on Windows with MSVS 2019, this
commit:
- Silences a useless warning about a private member in dll-exported
Status class.
- Exports the File class used by packager.exe
- Removes the explicit File dependency in packager.exe in favor of
libpackager, now that File is exported
- Add missing defines in packager.exe and packager_test.exe that
instruct the linker to import Status and File from the library
Closes#318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: I091f1655d88d36f353f7df497101eef17729eefe
The Chromium sysroot has a broken C++11 implementation that doesn't
allow us to use <condition_variable> or <chrono>. So we need to use the
system sysroot to use all C++11 features.
Change-Id: I41bec7ebddf598e1bf0494ee8bb2844e67bc8acf
- Also fixed compilations in Alpine Linux and other flavors of Linux.
- Added container versions in docker files to always use a verified
version.
Closes#164.
Change-Id: I949a8709e4d70c49129c9c2e8608dd78193d964c
There are non-ASCII characters in comment section of some source
code, which is causing compilation problems on some systems with
a codepage that cannot represent these characters.
Fixes#419.
Change-Id: I20d68a201263d515290ee440b52c5354b739099a
- Update curl to 7.57.0
- Roll clang, which is needed due to MacOS / XCode update
- Fixes and suppress compilation errors due to clang update
Fixes#285
Change-Id: Ibac3288c641861605c3c0500d34d27373e6eecfe
Seeing some failures on some platforms when compiled with clang
disabled:
GYP_DEFINES="clang=0" gclient runhooks
Several changes to make it work:
1. Mark packager code with packager_code=1 in GYP definitions.
2. Disable a few checks in non-packager code, which we do not have
direct control: dangling-else, deprecated-declarations,
unused-function
3. Fix the relevant errors in packager code.
4. Revert HAVE_STROPTS_H in curl config which is not available in
all linux distributions.
Fixes#286Fixes#293
Change-Id: I729b41f99403c5ad9487c6cc4a7dc06f6323cef8
Shared libpackager can be built by setting libpackager_type to
shared_library, e.g.
GYP_DEFINES='libpackager_type=shared_library' gclient runhooks
ninja -C out/Debug
will generate libpackager.so in out/Debug/lib directory.
Here is a few other changes to make shared_library builds and
tests pass:
- Add several test parameters to packager.h, which is needed for
testing.
- Create a protoc.gypi from build/protoc.gypi but depending on
protobuf_full_do_not_use instead of protobuf_lite, since we need
protobuf_full_do_not_use for text parsing and generation of media
info proto. Somehow shared_library build does not allow mixed use
of protobuf_full_do_not_use and protobuf_lite.
- Remove the use of LazyInstance in version/version.cc and use static
variable directly. This is because LazyInstance needs AtExitManager
which may not be easy to setup when calling GetVersion.
- Allow skipping testPackageWvmInputWithoutStrippingParameterSetNalus
with flag --shared_library, which is needed as shared_library build
does not support --strip_parameter_set_nalus flag yet.
Fixes#227
Change-Id: Iff05a50baa28134faa7218664c96114cb9e70329
This is a follow up to previous CL.
Generated using command:
find {media,app,mpd} -type f -exec sed -r -i 's/#include "(.*)"/#include
"packager\/\1"/' {} \;
common.gypi and mpd.gyp are also modified to take the path change into
consideration.
Change-Id: I1fb102b4eb73ae5fde5f4ab303a12cec09b05c33