Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=771505
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=771505
|
|
We don't require it and it may fail to build for some platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=773244
|
|
On Windows, building 32-bit on 64-bit is not cross-compilation since
32-bit Windows binaries run on 64-bit Windows via WOW64. It is
indistinguishable from native compilation especially in our case since
our environment decides what toolchain we will use.
In fact, our MinGW toolchain consists of native 32-bit binaries being
run in 64-bit and building for 32-bit. The toolchain itself thinks it is
running on 32-bit.
|
|
On Windows, rtmp installs a duplicate DLL by trying to symlink which
results in a copy under MinGW since symlinks aren't supported there.
This causes gen_library_file to fail, and no import library is created.
|
|
|
|
This covers the case when the server is down or returns an error code,
but not if the server is stupid enough to return a webpage with an HTML
message. For that we need to add a file size and sha256sum check.
Once we have that, we can even add support for continuing downloads.
TODO: Fix tarball mirror URL
|
|
Just do it on Linux for now because we don't know what the state of the
certificate store is on other platforms. It's definitely broken on
Windows, for instance.
|
|
Otherwise we just mask the actual error with a new "file not found"
error.
|
|
This will print all source URLs and tarball names to stdout with
a prefix denoting their type. For now, only prints tarballs.
The tarball URLs have all been URL-encoded so that, for instance, spaces
are converted to %20. This makes it safer to parse stdout for the URL
and tarball name. Note that the tarball name can still contain spaces.
The recommended way of parsing the output is:
* Check if it begins with 'TARBALL: '
* If it does, read till the next space. This is your URL.
* Skip the space. Everything till newline is your tarball name.
This will be used to implement our tarball mirror setup on fdo.
|
|
If the prefix is executable, we do not need to build glib-tools
separately for use during the build process. We can just use the glib
binaries and scripts provided by the glib built by us.
|
|
Don't try to generate an import library if the sanity checks fail
|
|
Causes issues on osx/ios
|
|
In the process they nuked the old one completely and broke all
downloads: https://github.com/taglib/taglib/issues/764
|
|
With Xcode 8, building C++ code and targetting earlier than OS X 10.8
causes build failures, because older code is expected to use libstdc++
and the newly built code is built against libc++. So we just bump the
minimum requirement to 10.9.
|
|
|
|
|
|
Not all build systems read CPPFLAGS (some only read CFLAGS and friends)
and arch cflags are sometimes needed by header checks
Related to a6e18924d422d91eb076bed61baca1203591764f
Partially fixes https://bugzilla.gnome.org/show_bug.cgi?id=773423
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=773413
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=768493
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=768493
|
|
It's not specific to arm, but pretty much for any non-native build as
cerbero doesn't include python.
https://bugzilla.gnome.org/show_bug.cgi?id=768493
|
|
Clean up the different between cross-compiling, which means that the
target is not the build system, and executable prefix, which means that
the build system can execute binaries from the target prefix
https://bugzilla.gnome.org/show_bug.cgi?id=768493
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=768493
|
|
The latest version of file reports .crt files as a PEM certificate
instead of a generic text file. Also remove duplicate 'data' entry.
Fixes the ios-universal build on macOS 10.12
|
|
Fixes a build failure on OS X for iOS-universal (arm64).
Also remove an unused and useless patch.
|
|
While building for iOS/x86_64 on macOS 10.12, this fixes the same issue
that Android has while compiling for x86_64.
Undefined symbols for architecture x86_64:
"_rpl_malloc", referenced from:
_trie_create in make_at_dictionary-50049a.o
_trie_node_create in make_at_dictionary-50049a.o
ld: symbol(s) not found for architecture x86_64
|
|
With macOS 10.12, file never outputs 'ERROR'. When it isn't sure what
a file is, it outputs hex code describing the file. If we can't figure
out what a file is and it seems to be a header, just copy it.
|
|
The linker on OS X and iOS for instance doesn't support the
--version-script argument.
Fixes the build on OS X. iOS still fails with a different error in this
same recipe.
|
|
With Autotools, CPPFLAGS is added to CFLAGS, but not with CMake, so we
need to duplicate it there.
Gosh, so many iterations to fix this.
|
|
|
|
Add a configuration option for the minimum iOS version to target, and
add it to the xcode8 workaround utility function. iOS 10.0 introduced
the same issue as macOS 10.12 w.r.t. symbol availability.
|
|
This allows checks like AC_CHECK_HEADER and others to use the correct
headers. Also, don't need to set them in CFLAGS, CXXFLAGS, etc if
they're in CPPFLAGS.
|
|
We include this config twice for universal builds, so avoid
overly-verbose CFLAGS/LDFLAGS/etc by only appending if not already in
the list
|
|
xcodebuild takes a 'Path' argument that directly gives us that path
|
|
ab27e50941262a79d8975eebd76945f2300c5145 was incomplete and references
the removed platform_str variable.
https://bugzilla.gnome.org/show_bug.cgi?id=772826
|
|
We need to include <stdint.h>
|
|
Instead of picking a random architecture, instead save the failed on in
the exception and use it to go to the right directory.
https://bugzilla.gnome.org/show_bug.cgi?id=772208
|
|
|
|
macOS 10.12 added a bunch of new symbols: clock_gettime, getentropy,
mkostemp, etc. These are available in the macOS 10.12 SDK. However,
XCode 8 now only ships that version of the SDK, and because of the way
the symbols are defined, they are always detected as being available
regardless of what OS X version you are actually targetting.
Long story short, the only way around this is to workaround it by
forcibly disabling detection of these symbols when we're targetting OS
X versions older than 10.12. For more details, see:
https://bugzilla.gnome.org/show_bug.cgi?id=772451
|
|
We don't even use tar for unpacking, and it seems BSD tar is enough for
everything else.
|
|
This reverts commit ba5ab589aae383c1b388b3eb7ee13feea847900f.
Uh, didn't notice this was already fixed.
|
|
Google Code has been archived, and the link broke
|
|
|
|
Earlier, when we encountered an incomplete or corrupted tarball, we
would error out with a CRC check error (for tarballs) or similar. This
error would not fix itself if you build the recipe from scratch because
the 'fetch' stage just checks if the file exists, and if it does,
assumes that it downloaded successfully.
You had to manually remove the file, and then when 'extract' errored
out because the file didn't exist, you'd have to select '1' to build the
recipe from scratch. This is extremely confusing.
Now we just overwrite and try to redownload the file once if it's
corrupted or partially downloaded.
|
|
Detecting the 'native' architecture of Windows is not a trivial task.
We cannot trust that the architecture that Python is built for is the
'native' one because you can run 32-bit apps on 64-bit Windows using
WOW64 and people sometimes install 32-bit Python on 64-bit Windows.
|
|
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from: /[...]/cerbero/build/build-tools/bin/xz
Expected in: /usr/lib/libSystem.B.dylib
|
|
|