[swift-build-dev] Hard-Coded Paths in glibc.modulemap
swift-build-dev at synthetel.com
Wed Jun 8 22:14:01 CDT 2016
Thank you for your kind response.
As mentioned, there is no choice: If the headers aren't present in the
base image that a particular Cloud provider provides, they can only be
present in the application sand-box by one's own hand.
All Swift build-packs to date and to my knowledge use Swift 2.2 and do
not use the Swift 3 'swift build' process. I'm trying to develop the
T: +1.9053927729 <tel:+1.9053927729>
E: swift-build-dev at synthetel.com
On 6/8/2016 23:08, Daniel Dunbar wrote:
> Why do you want the headers inside the app sandbox? Usually they would remain outside.
> Have you looked at IBM's CloudFoundry build pack (https://github.com/IBM-Swift/swift-buildpack)? How does it handle the problem you are trying to solve?
> - Daniel
>> On Jun 8, 2016, at 8:03 PM, Shao Miller via swift-build-dev <swift-build-dev at swift.org> 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' wants to do something with the /usr/lib/swift/linux/x86_64/glibc.modulemap file, but that file contains a hard-coded path to a ///usr/include/complex.h header-file. As is usually the case, this hard-coded path will only work in a narrow set of environments, which excludes "the hole" that CloudFoundry provides. I have attempted to use '-Xcc -I/the/hole' and '-Xswiftc -I/the/hole' command-line arguments, but I do not observe these paths (nor sub-paths) being tried for the complex.h header-file during complication. I used 'strace' to trace the compilation process, including all subprocesses.
>> Is there some other mechanism to instruct the Swift 3 package manager that its [unfortunately] hard-coded paths are relative to some particular path? If not, would it be sensible to introduce some logic to specify such a prefix path?
>> Thank you for your time and attention.
>> Shao Miller
>> Synthetel Corporation
>> T: +1.9053927729 <tel:+1.9053927729>
>> E: swift-build-dev at synthetel.com
>> W: https://www.synthetel.com
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-build-dev