[swift-build-dev] Swift Build Missing LD_LIBRARY_PATH

[Shao Miller]

Good day, folks.

I am using the cflinux2fs environment (whose base OS is Ubuntu 14.04.4 
LTS) suggested by Brian Croom. I have downloaded the following Swift:

https://swift.org/builds/development/ubuntu1404/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a-ubuntu14.04.tar.gz

I have extracted it and its dependencies into the /app/.delta/ 
directory.  I am issuing the following command:

    swift build -Xcc -I/app/.delta/ -Xswiftc -I/app/.delta/ -Xlinker 
-L/app/.delta/ -v

I observe the following error:

    /home/vcap/app/.delta/usr/bin/clang++: error while loading shared 
libraries: libLLVM-3.4.so.1: cannot open shared object file: No such 
file or directory

The library is present at 
/app/.delta/usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1

The environment for BASh includes both LIBRARY_PATH and LD_LIBRARY_PATH 
variables, which both include the
/app/.delta/usr/lib/x86_64-linux-gnu/ directory.  These variables are 
both exported.  Once again, the environment that clang++ is created 
withdoes not include these critical environment variables.  The -Xlinker 
doesn't seem to be helping, either.

My questions are:

Is my expectation for -Xlinker incorrect?  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 inherited 
environment-variables to its child process(es)?

Shao Miller
Synthetel Corporation
E: swift-build-dev at synthetel.com
W: https://www.synthetel.com

On 6/8/2016 23:03, Shao Miller via swift-build-dev wrote:
> 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
> [prototype] source-code.
>
> 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.