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><br>torsdag 9 juni 2016 skrev Daniel Dunbar via swift-build-dev &lt;<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a>&gt;:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jun 9, 2016, at 8:35 AM, Shao Miller via swift-build-dev &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a>&gt; wrote:</div><br><div>
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <tt>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></tt></div></div></blockquote><div><br></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&#39;t explained how your environment is different yet.</div><div><br></div><div> - Daniel</div><div><br></div><div><blockquote type="cite"><div><div bgcolor="#FFFFFF" text="#000000"><tt>
      <br>
      This is why I&#39;m asking about whether or not it&#39;s reasonable for
      Swift to avoid hard-coded paths, or to at least allow a given
      prefix to be specified.<br>
    </tt>
    <div><br>
      Shao Miller<br>
      Synthetel Corporation<br>
      T: <a href="tel:+1.9053927729" target="_blank">+1.9053927729</a><br>
      E: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@synthetel.com&#39;);" target="_blank">swift-build-dev@synthetel.com</a><br>
      W: <a href="https://www.synthetel.com/" target="_blank">https://www.synthetel.com</a><br>
      <br>
    </div>
    <div>On 6/9/2016 11:31, Daniel Dunbar wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">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><br>
        </div>
        <div> - Daniel</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Thu, Jun 9, 2016 at 5:32 AM, Brian
          Croom via swift-build-dev <span dir="ltr">&lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank"></a><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a>&gt;</span>
          wrote:<br>
          <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><br>
            </div>
            <div>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><br>
            </div>
            <div>This old bug contains some tidbits that may also help
              you understand what&#39;s going on here: <a href="https://bugs.swift.org/plugins/servlet/mobile#issue/SR-15" target="_blank"></a><a href="https://bugs.swift.org/plugins/servlet/mobile#issue/SR-15" target="_blank">https://bugs.swift.org/plugins/servlet/mobile#issue/SR-15</a></div>
            <div><br>
            </div>
            <div>Brian
              <div>
                <div><br>
                  <br>
                  torsdag 9 juni 2016 skrev Shao Miller &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@synthetel.com&#39;);" target="_blank"></a><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@synthetel.com&#39;);" target="_blank">swift-build-dev@synthetel.com</a>&gt;:<br>
                  <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>
                    <br>
                    The command I execute is: swift build -Xcc
                    -I/app/.delta/ -Xswiftc -I/app/.delta/ -v<br>
                    <br>
                    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>
                    <br>
                    <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 &#39;///usr/include/complex.h&#39; not found<br>
                            header &quot;///usr/include/complex.h&quot;<br>
                                   ^<br>
                      &lt;unknown&gt;:0: error: could not build
                      Objective-C module &#39;SwiftGlibc&#39;<br>
                      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>
                    </blockquote>
                    <br>
                    Thank you for pointing out that these build-packs
                    are using &#39;swift build&#39;.  The two build-packs I&#39;d
                    looked at earlier today did not and I thought I&#39;d
                    recalled them having derived from the others you&#39;ve
                    mentioned.  I was mistaken.  My command somewhat
                    resembles the IBM Bluemix build-pack command[1],
                    which is:<br>
                    swift build --configuration release -Xcc -fblocks
                    -Xcc -I$BUILD_DIR/.apt/usr/include ...and so on...<br>
                    <br>
                    I am using this[2] Swift.  Running &#39;strace&#39; on the
                    BASh and all of its subprocesses during the
                    compilation yields only these two instances of
                    &quot;complex&quot;:<br>
                    <br>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      [pid 28678] stat(&quot;///usr/include/complex.h&quot;,
                      0x7ffe84061ef0) = -1 ENOENT (No such file or
                      directory)<br>
                      [pid 28679] write(2, &quot;header
                      &#39;///usr/include/complex.h&#39; not found&quot;, 43) = 43<br>
                    </blockquote>
                    <br>
                    Am I making an obvious mistake?<br>
                    <br>
                    [1] <a href="https://github.com/IBM-Swift/swift-buildpack/blob/bluemix-buildpack/bin/compile#L116" target="_blank">https://github.com/IBM-Swift/swift-buildpack/blob/bluemix-buildpack/bin/compile#L116</a><br>
                    [2] <a 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">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>
                    <br>
                    Shao Miller<br>
                    Synthetel Corporation<br>
                    T: <a href="tel:%2B1.9053927729" value="+19053927729" target="_blank">+1.9053927729</a> &lt;tel:<a href="tel:%2B1.9053927729" value="+19053927729" target="_blank">+1.9053927729</a>&gt;<br>
                    E: <a>swift-build-dev@synthetel.com</a><br>
                    W: <a href="https://www.synthetel.com/" target="_blank">https://www.synthetel.com</a><br>
                    <br>
                    On 6/9/2016 01:15, Brian Croom wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      IBM&#39;s buildpack as well as the ones from which it
                      descends (<a href="https://github.com/cloudfoundry-community/swift-buildpack" target="_blank">https://github.com/cloudfoundry-community/swift-buildpack</a>
                      and <a href="https://github.com/kylef/heroku-buildpack-swift" target="_blank">https://github.com/kylef/heroku-buildpack-swift</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>
                      <br>
                      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>
                      <br>
                      Brian<br>
                      <br>
                      onsdag 8 juni 2016 skrev Shao Miller via
                      swift-build-dev &lt;<a>swift-build-dev@swift.org</a>
                      &lt;mailto:<a>swift-build-dev@swift.org</a>&gt;&gt;:<br>
                      <br>
                          Thank you for your kind response.<br>
                      <br>
                          As mentioned, there is no choice: If the
                      headers aren&#39;t present in<br>
                          the base image that a particular Cloud
                      provider provides, they can<br>
                          only be present in the application sand-box by
                      one&#39;s own hand.<br>
                      <br>
                          All Swift build-packs to date and to my
                      knowledge use Swift 2.2<br>
                          and do not use the Swift 3 &#39;swift build&#39;
                      process.  I&#39;m trying to<br>
                          develop the next generation.<br>
                      <br>
                          Shao Miller<br>
                          Synthetel Corporation<br>
                          T: <a href="tel:%2B1.9053927729" value="+19053927729" target="_blank">+1.9053927729</a> &lt;tel:<a href="tel:%2B1.9053927729" value="+19053927729" target="_blank">+1.9053927729</a>&gt;<br>
                          E: <a>swift-build-dev@synthetel.com</a><br>
                          &lt;<a>javascript:_e(%7B%7D,&#39;cvml</a>&#39;,&#39;<a></a><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@synthetel.com&#39;);" target="_blank">swift-build-dev@synthetel.com</a>&#39;);&gt;<br>
                          W: <a href="https://www.synthetel.com/" target="_blank">https://www.synthetel.com</a><br>
                      <br>
                          On 6/8/2016 23:08, Daniel Dunbar wrote:<br>
                      <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>
                        <br>
                        <br>
                        <br>
                            Have you looked at IBM&#39;s CloudFoundry build
                        pack (<a href="https://github.com/IBM-Swift/swift-buildpack" target="_blank">https://github.com/IBM-Swift/swift-buildpack</a>)?
                        How does it handle the problem you are trying to
                        solve?<br>
                        <br>
                        <br>
                        <br>
                              - Daniel<br>
                        <br>
                        <br>
                        <br>
                        <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&lt;<a></a><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a>&gt;<br>
                              &lt;<a>javascript:_e(%7B%7D,&#39;cvml</a>&#39;,&#39;<a></a><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a>&#39;);&gt; 
                          wrote:<br>
                          <br>
                          <br>
                          <br>
                              Good day, Swift package manager
                          development folks.<br>
                          <br>
                          <br>
                          <br>
                              (There are at least two separate issues
                          being inquired about, but with the same
                          introductory context.)<br>
                          <br>
                          <br>
                          <br>
                              &quot;Cloudy&quot; deployment options derived from
                          or akin to CloudFoundry are agonizingly
                          locked-down environments.  Essentially Swift
                          and all of its dependencies and one&#39;s
                          project&#39;s dependencies must be stuffed into an
                          arbitrary directory (henceforth referred to as
                          &quot;the hole,&quot; but usually /app/ ) and build
                          processes performed without any root-user
                          privileges.  One consequence is that one
                          cannot use the OS&#39; package-management system
                          to install dependencies, but one must obtain
                          them and wrestle them into &quot;the hole,&quot;
                          instead.  The strategy seems rather silly.<br>
                          <br>
                          <br>
                          <br>
                              While developing a so-called &quot;buildpack&quot;
                          for Swift 3 projects to be deployed via
                          CloudFoundryish options and utilizing the
                          &#39;swift build&#39; command, I have come across a
                          few issues.<br>
                          <br>
                          <br>
                          <br>
                              One issue is that &#39;swift build&#39; 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 &quot;the hole&quot; that CloudFoundry
                          provides.  I have attempted to use &#39;-Xcc
                          -I/the/hole&#39; and &#39;-Xswiftc -I/the/hole&#39;
                          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 &#39;strace&#39; to trace the
                          compilation process, including all
                          subprocesses.<br>
                          <br>
                          <br>
                          <br>
                              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>
                          <br>
                          <br>
                          <br>
                              Thank you for your time and attention.<br>
                          <br>
                              -- <br>
                          <br>
                          <br>
                              Shao Miller<br>
                          <br>
                              Synthetel Corporation<br>
                          <br>
                              T: <a href="tel:%2B1.9053927729" value="+19053927729" target="_blank">+1.9053927729</a>
                          &lt;tel:<a href="tel:%2B1.9053927729" value="+19053927729" target="_blank">+1.9053927729</a>&gt;<br>
                          <br>
                              <a>E:swift-build-dev@synthetel.com</a><br>
                              &lt;<a>javascript:_e(%7B%7D,&#39;cvml</a>&#39;,&#39;<a></a><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@synthetel.com&#39;);" target="_blank">swift-build-dev@synthetel.com</a>&#39;);&gt;<br>
                          <br>
                              W:<a href="https://www.synthetel.com/" target="_blank">https://www.synthetel.com</a><br>
                          <br>
                          <br>
                          <br>
                             
                          _______________________________________________<br>
                          <br>
                              swift-build-dev mailing list<br>
                          <br>
                              <a>swift-build-dev@swift.org</a><br>
                              &lt;<a>javascript:_e(%7B%7D,&#39;cvml</a>&#39;,&#39;<a></a><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a>&#39;);&gt;<br>
                          <br>
                              <a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br>
                          <br>
                        </blockquote>
                      </blockquote>
                      <br>
                    </blockquote>
                    <br>
                  </blockquote>
                </div>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            swift-build-dev mailing list<br>
            <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a><br>
            <a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>swift-build-dev mailing list<br><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br></div></blockquote></div><br></div></blockquote>