[swift-build-dev] Hard-Coded Paths in glibc.modulemap
Shao Miller
swift-build-dev at synthetel.com
Mon Jul 4 19:27:36 CDT 2016
Thank you again.
My answers two your two questions are: Ubuntu 14.04. From here[3].
(Despite having shared this[2] link below, by mistake.)
The CloudFoundry build process is an automated process which involves
downloading Swift. If that automated process then further has to modify
portions of Swift source-code to "play nice" with the Cloud Foundry
build environment's [silly] limitations, that is very tedious and means
that a "delta" for a specific version of Swift has to be integrated into
the automated build process. I am suggesting that hard-coded paths in
Swift source-code is not a good idea and I am hopeful to meet with
agreement or with a discovery that I'm missing a key idea for why these
paths ought to remain hard-coded.
My two questions are:
On 6/8/2016 23:03, Shao Miller via swift-build-dev wrote:
> 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?
[3]
https://swift.org/builds/development/ubuntu1404/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a-ubuntu14.04.tar.gz
Shao Miller
Synthetel Corporation
T: +1.9053927729 <tel:+1.9053927729>
E: swift-build-dev at synthetel.com
W: https://www.synthetel.com
On 6/9/2016 08:32, Brian Croom wrote:
> What underlying OS is your build process running on? And where are you
> getting your Swift toolchain?
>
> Within your toolchain is a `glibc.modulemap` which contains hard-coded
> absolute paths to certain system headers. The failure you are seeing
> is presumably due to the fact that system headers are not present at
> those paths. You may have to manually modify the modulemap to point to
> the actual location of the headers on the system that is performing
> the build.
>
> This old bug contains some tidbits that may also help you understand
> what's going on here:
> https://bugs.swift.org/plugins/servlet/mobile#issue/SR-15
>
> Brian
>
> torsdag 9 juni 2016 skrev Shao Miller <swift-build-dev at synthetel.com
> <mailto:swift-build-dev at synthetel.com>>:
>
> Thank you for your kind response.
>
> The command I execute is: swift build -Xcc -I/app/.delta/ -Xswiftc
> -I/app/.delta/ -v
>
> The /app/.delta/ directory is where Swift and most dependencies
> have been dumped. The file /app/.delta/usr/include/complex.h
> exists. The error is:
>
> /app/.delta/usr/lib/swift/linux/x86_64/glibc.modulemap:33:14:
> error: header '///usr/include/complex.h' not found
> header "///usr/include/complex.h"
> ^
> <unknown>:0: error: could not build Objective-C module
> 'SwiftGlibc'
> error: exit(1): /app/.delta/usr/bin/swiftc --driver-mode=swift
> -I /app/.delta/usr/lib/swift/pm -L
> /app/.delta/usr/lib/swift/pm -lPackageDescription
> /app/PerfectTemplate/Package.swift -fileno 3
>
>
> Thank you for pointing out that these build-packs are using 'swift
> build'. The two build-packs I'd looked at earlier today did not
> and I thought I'd recalled them having derived from the others
> you've mentioned. I was mistaken. My command somewhat resembles
> the IBM Bluemix build-pack command[1], which is:
> swift build --configuration release -Xcc -fblocks -Xcc
> -I$BUILD_DIR/.apt/usr/include ...and so on...
>
> I am using this[2] Swift. Running 'strace' on the BASh and all of
> its subprocesses during the compilation yields only these two
> instances of "complex":
>
> [pid 28678] stat("///usr/include/complex.h", 0x7ffe84061ef0) =
> -1 ENOENT (No such file or directory)
> [pid 28679] write(2, "header '///usr/include/complex.h' not
> found", 43) = 43
>
>
> Am I making an obvious mistake?
>
> [1]
> https://github.com/IBM-Swift/swift-buildpack/blob/bluemix-buildpack/bin/compile#L116
> [2]
> https://swift.org/builds/development/ubuntu1510/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a-ubuntu15.10.tar.gz
>
> Shao Miller
> Synthetel Corporation
> T: +1.9053927729 <tel:+1.9053927729>
> E: swift-build-dev at synthetel.com
> W: https://www.synthetel.com
>
> On 6/9/2016 01:15, Brian Croom wrote:
>
> IBM's buildpack as well as the ones from which it descends
> (https://github.com/cloudfoundry-community/swift-buildpack and
> https://github.com/kylef/heroku-buildpack-swift) are all based
> around SwiftPM and the `swift build` command. I have not
> personally experienced the problem you are describing either,
> although I have not tried pushing any apps using more recent
> Swift toolchain snapshots.
>
> Can you provide more details about how the error presents
> itself? Have you tried using any of these other buildpacks
> with your app code?
>
> Brian
>
> onsdag 8 juni 2016 skrev Shao Miller via swift-build-dev
> <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>>:
>
> 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 next generation.
>
> Shao Miller
> Synthetel Corporation
> T: +1.9053927729 <tel:+1.9053927729>
> E: swift-build-dev at synthetel.com
>
> <javascript:_e(%7B%7D,'cvml','swift-build-dev at synthetel.com');>
> W: https://www.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>
>
> <javascript:_e(%7B%7D,'cvml','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
>
> <javascript:_e(%7B%7D,'cvml','swift-build-dev at synthetel.com');>
>
> W:https://www.synthetel.com
>
>
>
> _______________________________________________
>
> swift-build-dev mailing list
>
> swift-build-dev at swift.org
>
> <javascript:_e(%7B%7D,'cvml','swift-build-dev at swift.org');>
>
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
>
More information about the swift-build-dev
mailing list