[swift-build-dev] Swift Build Missing LD_LIBRARY_PATH

Daniel Dunbar daniel_dunbar at apple.com
Thu Jul 21 13:26:39 CDT 2016 

Hi Shao,

You are right, this is a very big issue currently. The unfortunate reality of SwiftPM is that it is still very early days, and while people are doing all sorts of interesting cool things with it, there are also a long list of major limitations.

We do have some bugs tracking this area, like:
  https://bugs.swift.org/browse/SR-2048
  https://bugs.swift.org/browse/SR-1968

That said, I know many people are able to get some things running on various PaaS platforms (including Heroku and CloudFoundry-based things) so it is not completely blocking use in those environments.

 - Daniel

> On Jul 21, 2016, at 11:07 AM, Shao Miller via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> Does this issue not appear to block Swift from being a successful back-end choice with CloudFoundry-based application-deployment options, including Pivotal, Heroku and IBM Bluemix?  I'm surprised and disappointed by the lack of discussion.  I would guess that it would be unfortunate to release Swift 3 and find that no CloudFoundry people can use it because it (Swift) doesn't co-operate with the limitations of those environments.
> 
> Shao Miller
> Synthetel Corporation
> E: swift-build-dev at synthetel.com
> W: https://www.synthetel.com
> 
> On 7/12/2016 20:43, Shao Miller via swift-build-dev wrote:
>> 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
>> 
>> _______________________________________________
>> 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

More information about the swift-build-dev mailing list