The IBM build pack installs a number of system dependencies
which should include those headers, though. You should have the
headers rooted at /usr, not try and have them in the app sandbox.
- Daniel
On Thu, Jun 9, 2016 at 5:32 AM, Brian Croom via swift-build-dev >>>> <swift-build-dev@swift.org >>>> <javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');>> 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:
Issues · apple/swift · GitHub
Brian
torsdag 9 juni 2016 skrev Shao Miller
<swift-build-dev@synthetel.com
<javascript:_e(%7B%7D,'cvml','swift-build-dev@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:%2B1.9053927729>
<tel:+1.9053927729 <tel:%2B1.9053927729>>
E: swift-build-dev@synthetel.com
W: https://www.synthetel.com <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
(GitHub - 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@swift.org
<mailto:swift-build-dev@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:%2B1.9053927729>
<tel:+1.9053927729 <tel:%2B1.9053927729>>
E: swift-build-dev@synthetel.com
<javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com
<javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com');>');>
W: https://www.synthetel.com
<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@swift.org
<javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');>>
<javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org
<javascript:_e(%7B%7D,'cvml','swift-build-dev@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:%2B1.9053927729>
<tel:+1.9053927729 <tel:%2B1.9053927729>>
E:swift-build-dev@synthetel.com
<javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com
<javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com');>');>
W:https://www.synthetel.com
<https://www.synthetel.com/>
_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
<javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org
<javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');>');>
https://lists.swift.org/mailman/listinfo/swift-build-dev
_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
<javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-build-dev