- Nov 21, 2016
-
-
Sebastian Dröge authored
If we generate .lib files with dlltool, they won't work very well with Visual Studio and can result in missing symbols. https://sourceware.org/bugzilla/show_bug.cgi?id=12633 https://bugzilla.gnome.org/show_bug.cgi?id=773889
-
- Nov 17, 2016
-
-
Sebastian Dröge authored
-
- Nov 02, 2016
-
-
Sebastian Dröge authored
-
- Nov 01, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
-
We don't require it and it may fail to build for some platforms. https://bugzilla.gnome.org/show_bug.cgi?id=773244
-
- Oct 28, 2016
-
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
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.
-
- Oct 27, 2016
-
-
Nirbheek Chauhan authored
-
Nirbheek Chauhan authored
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
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
Otherwise we just mask the actual error with a new "file not found" error.
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
Don't try to generate an import library if the sanity checks fail
-
- Oct 26, 2016
-
-
Causes issues on osx/ios
-
Nirbheek Chauhan authored
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.
-
-
- Oct 24, 2016
-
-
Olivier Crête authored
-
Nirbheek Chauhan authored
Not all build systems read CPPFLAGS (some only read CFLAGS and friends) and arch cflags are sometimes needed by header checks Related to a6e18924 Partially fixes https://bugzilla.gnome.org/show_bug.cgi?id=773423
-
- Oct 20, 2016
-
-
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
- Oct 19, 2016
-
-
Nirbheek Chauhan authored
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
-
Nirbheek Chauhan authored
Fixes a build failure on OS X for iOS-universal (arm64). Also remove an unused and useless patch.
-
Nirbheek Chauhan authored
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
-
- Oct 18, 2016
-
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
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.
-
Nirbheek Chauhan authored
We include this config twice for universal builds, so avoid overly-verbose CFLAGS/LDFLAGS/etc by only appending if not already in the list
-
Nirbheek Chauhan authored
xcodebuild takes a 'Path' argument that directly gives us that path
-