[swift-build-dev] Swift Build Missing LD_LIBRARY_PATH

[Shao Miller]

Good day, Swift build folks.

Given that nobody has volunteered an answer, does anyone have any 
suggestions for how I should best pursue the answer to this question?  
Should I track down where the sub-process is spawned, then 'git blame' 
and contact the author, directly?

Thanks for reading.

- Shao Miller

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