Summary:
X-link: https://github.com/facebookincubator/zstrong/pull/992
OSS Builds currently fail due to libcurl conflicting with libcurl-minimal. As far as I can tell, there are no blockers for moving FBOSS to use libcurl-minimal instead of libcurl.
Reviewed By: srikrishnagopu
Differential Revision:
D62759136
Privacy Context Container: L1125642
fbshipit-source-id: 79aa7fcc6f651cc074198f94e688b34b629a997f
Summary:
X-link: https://github.com/facebookincubator/zstrong/pull/907
I don't sure that I make all in accordance with the your contribution pipeline, so please correct me If there is needed.
So, I've made some changes to support the `pacman` package manager in your `getdeps.py` script. In `manifests` I'm also duplicated some packages from `debs` and `rpms` sections and create a new `pps` sections with according packages for `pacman`.
Issue: https://github.com/facebook/folly/issues/1701
X-link: https://github.com/facebook/folly/pull/1702
Reviewed By: yfeldblum
Differential Revision: D33514769
Pulled By: Orvid
fbshipit-source-id: a081c3a5bcb7f7cdde3a4a91c0d15517c0a171b3
Summary:
From the outset, we wanted to be sure that getdeps was able
to source and build the dependencies so that we knew that we'd have
a repeatable build. This came at the cost of build times: having
to build boost on each CI run is a bit of a chore.
This commit adds three new elements to the manifest files:
* `rpms` - a list of RPM names that are all required to be present
in order to consider the dependency satisfied
* `debs` - like `rpms` above, but scoped to debian package names
* `preinstalled.env` - a list of environment variables that if they
are all set and non-empty will satisfy the dependency.
A new `--allow-system-packages` option to getdeps enables the new
logic that looks for system packages; it is off by default, but
enabled in the generated GitHub Actions workflows.
A new `install-system-deps` subcommand is provided that will attempt
to install the system packages needed to satisfy the build. This
typically needs to be run via sudo and is thus broken out separately
from the main getdeps build flow.
I made a pass over the manifest files and added package names that
satisfy the build on ubuntu-18 and fedora-31.
shri-khare: I renamed the `Python3.7.6` manifest to just `python` as
part of this change; the version of python that it pulls in through
the normal build is the same and I believe that an equal or newer
version of python3 is available in the GH actions builder.
The `preinstalled.env` is used only by the boost manifest: it references
the name of an environment variable that is set by the github
windows hosts and that points to a pre-built and pre-installed
copy of boost. Since there is no package manager that we can
easily query for this sort of thing, probing from the environment
seems like a reasonable and fast way to check for this. We
may need to evolve this over time to become more feature rich,
but this seems like a good starting point.
This commit has the potential to save 20 minutes of build time
from each public CI build just due to the boost dependency alone!
Refs: https://github.com/facebook/watchman/pull/797
Reviewed By: yfeldblum
Differential Revision: D20740410
fbshipit-source-id: 6c38019449c54465127656c3d18a6ff1f30adaea
Summary:
We are seeing random segment fault originating from OpenSSL on macOS when
Mononoke fetching is enabled.
The cause is that on macOS we are actually linking against libcurl shipped with
the system instead of ours. That copy of libcurl is linked with macOS's
libcrypto instead of the one we compiles during Eden's build, and it seems that
version of libcrypto does not provide concurrency safety.
The solution is to build curl on macOS and make sure it is linked to our
OpenSSL that has the concurrency callbacks registered.
Reviewed By: wez
Differential Revision: D17657822
fbshipit-source-id: 85abdf3be10b3903a5efc6b3a91624c7258de790
Summary:
D15683387 introduced manifest for libcurl and used cmake instead of autoconf
(rationale: having cmake build curl would make it easy as we want curl to build
on windows and macos).
if libcurl finds ldap.h, then it builds with ldap enabled.
On my devserver, ldap library is not installed, and thus libcurl builds without
it, and links with FBOSS binaries fine.
In sandbox, ldap seems to be installed, thus libcurl builds with ldap. However,
linking fails for FBOSS binaries as those don't link against ldap - FBOSS does
not depend on ldap.
Thus, we need a way to configure libcurl with ldap disabled. [cmake.defines]
CURL_DISABLE_LDAP=OFF, does not quite do it. Thus, am going with autoconf, with
args --disable-ldap for now for Linux and cmake for non-Linux environments.
Reviewed By: wez
Differential Revision: D15730947
fbshipit-source-id: 2ce48976ee785401d550720cbdccb22f9d416675
Summary:
This is towards getting open source FBOSS to build using fbcode_builder.
libcurl is one of the dependencies for FBOSS. This patch adds a manifest
file to build libcurl.
Reviewed By: wez
Differential Revision: D15683387
fbshipit-source-id: 8df5c413e7dff06d1a19e0ce3b1706bff2f1ab54
