[swift-build-dev] Swift Build Missing LD_LIBRARY_PATH

[Shao Miller]

Please disregard my mention of -Xlinker, as I was temporarily confused 
by the error-message.

If I rename clang to clang.orig and introduce a fake clang as a script 
that establishes LD_LIBRARY_PATH and invokes clang.orig, all is well. 
This allows the following question to remain:

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
T: +1.9053927729 <tel:+1.9053927729>
E: swift-build-dev at synthetel.com
W: https://www.synthetel.com

On 7/4/2016 21:49, Shao Miller via swift-build-dev wrote:
> 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.
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev