[swift-corelibs-dev] [swift-dev] Linux: Build process not finding my ICU

[Eric Wing]

On 9/13/16, Will Stanton <willstanton1 at yahoo.com> wrote:
> Hello Eric,
>
> Not sure if this will help, but perhaps you can feed something in build.py?
> https://github.com/apple/swift-corelibs-foundation/blob/master/build.py
>
> You seem to be working under some tight constraints! Is installing ICU in
> /usr/local/ not possible?
>
> Regards,
> Will Stanton
>

Thanks for the reply. That was helpful in giving me a place to start.

So I'm trying to make it possible to build Swift binaries that can be
run on most modern Linux's. Steam-Runtime is my base as they are
heavily focused on binary distribution. I suppose I could put stuff
into my /usr/local since they do not use that directory for their
stuff. However, as a general principle, I try to avoid putting stuff
into installed areas because it makes auditing dependencies for binary
distribution harder later. The CMake build process is mostly aware
that components can be elsewhere, but this part of the build process
is not using CMake.


So I hacked up build.py, but it looks like I have additional problems.

Foundation is using newer features in libxml and libcurl than what I
have available. xmlXPathNodeEval and CURLOPT_XFERINFOFUNCTION seem to
be the biggest roadblocks at the moment.

But my bigger problem at the moment is build.py doesn't put the Link
flags in the right place. When it builds foundation, it puts the link
flags first, and then all the .o filles from Foundation. The link
flags need to be after all the .o files. Some of my dependencies are
static libraries, and I think if the link process tries to use a
library before the symbol is actually needed, it gets dropped early.
Then I get a massive amount of unresolved symbol errors. (I've
verified by manually invoking the command on the terminal myself.)

I would appreciate any thoughts/help on what I should look at changing
next. And I would like to do this in a way that might be accepted back
into the main source tree.

Thanks,
Eric