IBM&#39;s buildpack as well as the ones from which it descends (<a href="https://github.com/cloudfoundry-community/swift-buildpack">https://github.com/cloudfoundry-community/swift-buildpack</a> and <a href="https://github.com/kylef/heroku-buildpack-swift">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.<div><br></div><div>Can you provide more details about how the error presents itself? Have you tried using any of these other buildpacks with your app code?</div><div><br></div><div>Brian<br><div><div><br>onsdag 8 juni 2016 skrev Shao Miller 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 bgcolor="#FFFFFF" text="#000000">

    <tt>Thank you for your kind response.<br>

      <br>

      As mentioned, there is no choice: If the headers aren&#39;t present in

      the base image that a particular Cloud provider provides, they can

      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

      and do not use the Swift 3 &#39;swift build&#39; process.  I&#39;m trying to

      develop the next generation.<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/8/2016 23:08, Daniel Dunbar wrote:<br>

    </div>

    <blockquote type="cite">

      <pre>Why do you want the headers inside the app sandbox? Usually they would remain outside.



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?



 - Daniel



</pre>

      <blockquote type="cite">

        <pre>On Jun 8, 2016, at 8:03 PM, Shao Miller via swift-build-dev <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">&lt;swift-build-dev@swift.org&gt;</a> wrote:



Good day, Swift package manager development folks.



(There are at least two separate issues being inquired about, but with the same introductory context.)



&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.



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.



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.



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 &lt;tel:+1.9053927729&gt;

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>

W: <a href="https://www.synthetel.com" target="_blank">https://www.synthetel.com</a>



_______________________________________________

swift-build-dev mailing list

<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-build-dev@swift.org&#39;);" target="_blank">swift-build-dev@swift.org</a>

<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a>

</pre>

      </blockquote>

      <pre>
</pre>

    </blockquote>

    <br>

  </div>


</blockquote></div></div></div>