[swift-build-dev] Swift Build Missing LD_LIBRARY_PATH
swift-build-dev at synthetel.com
Wed Jun 8 22:03:33 CDT 2016
Good day, Swift package manager development folks.
(There are at least two separate issues being inquired about, but with
the same introductory context.)
"Cloudy" deployment options derived from or akin to CloudFoundry are
agonizingly locked-down environments. Essentially Swift and all of its
dependencies and one's project's dependencies must be stuffed into an
arbitrary directory (henceforth referred to as "the hole," but usually
/app/ ) and build processes performed without any root-user privileges.
One consequence is that one cannot use the OS' package-management system
to install dependencies, but one must obtain them and wrestle them into
"the hole," instead. The strategy seems rather silly.
While developing a so-called "buildpack" for Swift 3 projects to be
deployed via CloudFoundryish options and utilizing the 'swift build'
command, I have come across a few issues.
One issue is that 'swift build' invokes and 'swift-build' command, who
then invokes a 'swiftc' command, but the environment provided to this
last is insufficient for the dynamic loader to gain knowledge of
libraries present in "the hole" and specified by the LD_LIBRARY_PATH
variable. This variable and other environment-variables present for the
parent processes are not provided to the 'swiftc' command. This means
that libraries are searched for in the usual OS locations, but due to
the locked-down CloudFoundry environment, they won't be found. At one
point I was able to find a 'popen' in an older version of Swift that
seemed to be responsible, but I cannot find it in the Swift 3
Is there a good reason to discard these environment-variables, or would
it be reasonable to introduce some logic for 'swift-build' to pass its
environment-variables to its child 'swiftc' process(es)?
Thank you for your time and attention.
T: +1.9053927729 <tel:+1.9053927729>
E: swift-build-dev at synthetel.com
More information about the swift-build-dev