<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Thank you. The 'swiftc' command doesn't appear to care about
the '--sysroot' parameter with respect to header-paths. 'strace'
yields only examination of the absolute paths for the headers.</tt><br>
<div class="moz-signature"><br>
Shao Miller<br>
Synthetel Corporation<br>
T: <a href="tel:+1.9053927729">+1.9053927729</a><br>
E: <a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@synthetel.com">swift-build-dev@synthetel.com</a><br>
W: <a class="moz-txt-link-freetext" href="https://www.synthetel.com">https://www.synthetel.com</a><br>
<br>
</div>
<div class="moz-cite-prefix">On 6/9/2016 12:13, Daniel Dunbar wrote:<br>
</div>
<blockquote
cite="mid:C7E16589-4DBE-4890-998D-3B9B8FE58B49@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Ah, thanks! That was the missing piece of info and I missed that
in the script.
<div class=""><br class="">
</div>
<div class="">If you truly need to install a full set of headers
in a sandboxed location, then the compiler arguments to use to
point at that location are the `--sysroot` ones for Clang. I
haven't tried this myself, so YMMV, but something like `-Xcc
--sysroot -Xcc /app/.delta` *might* work.</div>
<div class=""><br class="">
</div>
<div class=""> - Daniel</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 9, 2016, at 9:09 AM, Brian Croom <<a
moz-do-not-send="true"
href="mailto:brian.s.croom@gmail.com" class=""><a class="moz-txt-link-abbreviated" href="mailto:brian.s.croom@gmail.com">brian.s.croom@gmail.com</a></a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Note that the IBM buildpack works around the
environmental restrictions by configuring apt-get to
install packages in subdirectories of the buildpack
sandbox, rather than in the standard system directories.
This works great, but can still cause issues with
components that search for things with absolute paths to
the standard directories. <br class="">
<br class="">
torsdag 9 juni 2016 skrev Daniel Dunbar via
swift-build-dev <<a moz-do-not-send="true"
href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>>:<br
class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jun 9, 2016, at 8:35 AM, Shao
Miller via swift-build-dev <<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');"
target="_blank" class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></a>>
wrote:</div>
<br class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<tt class="">Thanks, but let me try to explain
for a third time: The build environment
provided by CloudFoundry-style providers is
locked-down. You have no choice where
things go. They must all go inside a
sandbox. That means you cannot put headers
underneath the /usr/ directory. There is no
way out of the sandbox, as there are no
root-user privileges.<br class="">
</tt></div>
</div>
</blockquote>
<div class=""><br class="">
</div>
You have stated that, but the IBM build pack works,
uses CloudFoundry, and it clearly uses apt-get to
install things in the system. You haven't explained
how your environment is different yet.</div>
<div class=""><br class="">
</div>
<div class=""> - Daniel</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><tt
class=""> <br class="">
This is why I'm asking about whether or not
it's reasonable for Swift to avoid
hard-coded paths, or to at least allow a
given prefix to be specified.<br class="">
</tt>
<div class=""><br class="">
Shao Miller<br class="">
Synthetel Corporation<br class="">
T: <a moz-do-not-send="true"
href="tel:+1.9053927729" target="_blank"
class="">+1.9053927729</a><br class="">
E: <a moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com');"
target="_blank" class="">swift-build-dev@synthetel.com</a><br
class="">
W: <a moz-do-not-send="true"
href="https://www.synthetel.com/"
target="_blank" class="">https://www.synthetel.com</a><br
class="">
<br class="">
</div>
<div class="">On 6/9/2016 11:31, Daniel Dunbar
wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">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.
<div class=""><br class="">
</div>
<div class=""> - Daniel</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Thu, Jun 9,
2016 at 5:32 AM, Brian Croom via
swift-build-dev <span dir="ltr"
class=""><<a moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');"
target="_blank" class="">swift-build-dev@swift.org</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">What
underlying OS is your build process
running on? And where are you
getting your Swift toolchain?
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">This old bug contains
some tidbits that may also help you
understand what's going on here: <a
moz-do-not-send="true"
href="https://bugs.swift.org/plugins/servlet/mobile#issue/SR-15"
target="_blank" class=""><a class="moz-txt-link-freetext" href="https://bugs.swift.org/plugins/servlet/mobile#issue/SR-15">https://bugs.swift.org/plugins/servlet/mobile#issue/SR-15</a></a></div>
<div class=""><br class="">
</div>
<div class="">Brian
<div class="">
<div class=""><br class="">
<br class="">
torsdag 9 juni 2016 skrev Shao
Miller <<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com');"
target="_blank" class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@synthetel.com">swift-build-dev@synthetel.com</a></a>>:<br
class="">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">Thank
you for your kind response.<br
class="">
<br class="">
The command I execute is:
swift build -Xcc
-I/app/.delta/ -Xswiftc
-I/app/.delta/ -v<br class="">
<br class="">
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:<br
class="">
<br class="">
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
/app/.delta/usr/lib/swift/linux/x86_64/glibc.modulemap:33:14:
error: header
'///usr/include/complex.h'
not found<br class="">
header
"///usr/include/complex.h"<br
class="">
^<br class="">
<unknown>:0: error:
could not build Objective-C
module 'SwiftGlibc'<br
class="">
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<br class="">
</blockquote>
<br class="">
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:<br class="">
swift build --configuration
release -Xcc -fblocks -Xcc
-I$BUILD_DIR/.apt/usr/include
...and so on...<br class="">
<br class="">
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":<br class="">
<br class="">
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
[pid 28678]
stat("///usr/include/complex.h",
0x7ffe84061ef0) = -1 ENOENT
(No such file or directory)<br
class="">
[pid 28679] write(2, "header
'///usr/include/complex.h'
not found", 43) = 43<br
class="">
</blockquote>
<br class="">
Am I making an obvious
mistake?<br class="">
<br class="">
[1] <a moz-do-not-send="true"
href="https://github.com/IBM-Swift/swift-buildpack/blob/bluemix-buildpack/bin/compile#L116"
target="_blank" class="">https://github.com/IBM-Swift/swift-buildpack/blob/bluemix-buildpack/bin/compile#L116</a><br
class="">
[2] <a moz-do-not-send="true"
href="https://swift.org/builds/development/ubuntu1510/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a-ubuntu15.10.tar.gz"
target="_blank" class="">https://swift.org/builds/development/ubuntu1510/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a/swift-DEVELOPMENT-SNAPSHOT-2016-05-31-a-ubuntu15.10.tar.gz</a><br
class="">
<br class="">
Shao Miller<br class="">
Synthetel Corporation<br
class="">
T: <a moz-do-not-send="true"
href="tel:%2B1.9053927729"
value="+19053927729"
target="_blank" class="">+1.9053927729</a>
<tel:<a
moz-do-not-send="true"
href="tel:%2B1.9053927729"
value="+19053927729"
target="_blank" class="">+1.9053927729</a>><br
class="">
E: <a moz-do-not-send="true"
class="">swift-build-dev@synthetel.com</a><br
class="">
W: <a moz-do-not-send="true"
href="https://www.synthetel.com/" target="_blank" class="">https://www.synthetel.com</a><br
class="">
<br class="">
On 6/9/2016 01:15, Brian Croom
wrote:<br class="">
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
IBM's buildpack as well as
the ones from which it
descends (<a
moz-do-not-send="true"
href="https://github.com/cloudfoundry-community/swift-buildpack"
target="_blank" class=""><a class="moz-txt-link-freetext" href="https://github.com/cloudfoundry-community/swift-buildpack">https://github.com/cloudfoundry-community/swift-buildpack</a></a>
and <a
moz-do-not-send="true"
href="https://github.com/kylef/heroku-buildpack-swift"
target="_blank" class=""><a class="moz-txt-link-freetext" href="https://github.com/kylef/heroku-buildpack-swift">https://github.com/kylef/heroku-buildpack-swift</a></a>)
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.<br class="">
<br class="">
Can you provide more details
about how the error presents
itself? Have you tried using
any of these other
buildpacks with your app
code?<br class="">
<br class="">
Brian<br class="">
<br class="">
onsdag 8 juni 2016 skrev
Shao Miller via
swift-build-dev <<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></a>
<mailto:<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></a>>>:<br
class="">
<br class="">
Thank you for your kind
response.<br class="">
<br class="">
As mentioned, there is
no choice: If the headers
aren't present in<br
class="">
the base image that a
particular Cloud provider
provides, they can<br
class="">
only be present in the
application sand-box by
one's own hand.<br class="">
<br class="">
All Swift build-packs to
date and to my knowledge use
Swift 2.2<br class="">
and do not use the Swift
3 'swift build' process.
I'm trying to<br class="">
develop the next
generation.<br class="">
<br class="">
Shao Miller<br class="">
Synthetel Corporation<br
class="">
T: <a
moz-do-not-send="true"
href="tel:%2B1.9053927729"
value="+19053927729"
target="_blank" class="">+1.9053927729</a>
<tel:<a
moz-do-not-send="true"
href="tel:%2B1.9053927729"
value="+19053927729"
target="_blank" class="">+1.9053927729</a>><br
class="">
E: <a
moz-do-not-send="true"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@synthetel.com">swift-build-dev@synthetel.com</a></a><br
class="">
<<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-freetext" href="javascript:_e(%7B%7D,'cvml">javascript:_e(%7B%7D,'cvml</a></a>','<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com');"
target="_blank" class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@synthetel.com">swift-build-dev@synthetel.com</a></a>');><br
class="">
W: <a
moz-do-not-send="true"
href="https://www.synthetel.com/"
target="_blank" class=""><a class="moz-txt-link-freetext" href="https://www.synthetel.com">https://www.synthetel.com</a></a><br
class="">
<br class="">
On 6/8/2016 23:08,
Daniel Dunbar wrote:<br
class="">
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
Why do you want the
headers inside the app
sandbox? Usually they
would remain outside.<br
class="">
<br class="">
<br class="">
<br class="">
Have you looked at
IBM's CloudFoundry build
pack (<a
moz-do-not-send="true"
href="https://github.com/IBM-Swift/swift-buildpack"
target="_blank" class=""><a class="moz-txt-link-freetext" href="https://github.com/IBM-Swift/swift-buildpack">https://github.com/IBM-Swift/swift-buildpack</a></a>)?
How does it handle the
problem you are trying to
solve?<br class="">
<br class="">
<br class="">
<br class="">
- Daniel<br class="">
<br class="">
<br class="">
<br class="">
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
On Jun 8, 2016, at
8:03 PM, Shao Miller via
swift-build-dev<<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');"
target="_blank"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></a>><br
class="">
<<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-freetext" href="javascript:_e(%7B%7D,'cvml">javascript:_e(%7B%7D,'cvml</a></a>','<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');"
target="_blank"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></a>');>
wrote:<br class="">
<br class="">
<br class="">
<br class="">
Good day, Swift
package manager
development folks.<br
class="">
<br class="">
<br class="">
<br class="">
(There are at least
two separate issues
being inquired about,
but with the same
introductory context.)<br
class="">
<br class="">
<br class="">
<br class="">
"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.<br class="">
<br class="">
<br class="">
<br class="">
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.<br class="">
<br class="">
<br class="">
<br class="">
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.<br
class="">
<br class="">
<br class="">
<br class="">
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?<br
class="">
<br class="">
<br class="">
<br class="">
Thank you for your
time and attention.<br
class="">
<br class="">
-- <br class="">
<br class="">
<br class="">
Shao Miller<br
class="">
<br class="">
Synthetel
Corporation<br class="">
<br class="">
T: <a
moz-do-not-send="true"
href="tel:%2B1.9053927729" value="+19053927729" target="_blank" class="">+1.9053927729</a>
<tel:<a
moz-do-not-send="true"
href="tel:%2B1.9053927729" value="+19053927729" target="_blank" class="">+1.9053927729</a>><br
class="">
<br class="">
<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-abbreviated" href="mailto:E:swift-build-dev@synthetel.com">E:swift-build-dev@synthetel.com</a></a><br
class="">
<<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-freetext" href="javascript:_e(%7B%7D,'cvml">javascript:_e(%7B%7D,'cvml</a></a>','<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@synthetel.com');"
target="_blank"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@synthetel.com">swift-build-dev@synthetel.com</a></a>');><br
class="">
<br class="">
W:<a
moz-do-not-send="true"
href="https://www.synthetel.com/" target="_blank" class=""><a class="moz-txt-link-freetext" href="https://www.synthetel.com">https://www.synthetel.com</a></a><br
class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br
class="">
<br class="">
swift-build-dev
mailing list<br class="">
<br class="">
<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></a><br
class="">
<<a
moz-do-not-send="true"
class=""><a class="moz-txt-link-freetext" href="javascript:_e(%7B%7D,'cvml">javascript:_e(%7B%7D,'cvml</a></a>','<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');"
target="_blank"
class=""><a class="moz-txt-link-abbreviated" href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></a>');><br
class="">
<br class="">
<a
moz-do-not-send="true"
href="https://lists.swift.org/mailman/listinfo/swift-build-dev"
target="_blank"
class=""><a class="moz-txt-link-freetext" href="https://lists.swift.org/mailman/listinfo/swift-build-dev">https://lists.swift.org/mailman/listinfo/swift-build-dev</a></a><br
class="">
<br class="">
</blockquote>
</blockquote>
<br class="">
</blockquote>
<br class="">
</blockquote>
</div>
</div>
</div>
<br class="">
_______________________________________________<br class="">
swift-build-dev mailing list<br
class="">
<a moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');"
target="_blank" class="">swift-build-dev@swift.org</a><br
class="">
<a moz-do-not-send="true"
href="https://lists.swift.org/mailman/listinfo/swift-build-dev"
rel="noreferrer" target="_blank"
class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br
class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
_______________________________________________<br
class="">
swift-build-dev mailing list<br class="">
<a moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','swift-build-dev@swift.org');"
target="_blank" class="">swift-build-dev@swift.org</a><br
class="">
<a moz-do-not-send="true"
href="https://lists.swift.org/mailman/listinfo/swift-build-dev"
target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>