[swift-dev] New to building Swift toolchain

Thu Sep 28 00:18:58 CDT 2017

So it must be something not related to the build tools being used. At least
I went though tons of variations on those.

It could be the particular version of simulator being used for running
tests on iPhone 5. Maybe the fact that I have multiple Xcode versions
contributes to that problem... I have 8.3.3, 9 and latest beta of 9.

If only I could get something like docker image to roll into my laptop to
get “vanilla” build environment....

I’ll try to see if somethings wrong with simulator setup and try to get my
hands on some Mac mini with clean Xcode 9 setup.

Cheers
Max
On Thu, 28 Sep 2017 at 4:27 am, Michael Gottesman <mgottesman at apple.com>
wrote:

> On Sep 26, 2017, at 3:57 PM, Maksym Grebenets <mgrebenets at gmail.com>
> wrote:
>
> Hi Michael
>
> Thanks for following up!
>
> I've found some extra time too to give it few more tries.
> As a matter of fact, I've tried quite a few things.
> Spoiler alert - none of them worked :)
> Here's the list of things anyways:
> - A completely clean checkout of sift repo and all submodules (still same
> laptop, but to be 100% there's no left overs of any kind)
> - Change LANG env var from en_GB.UTF-8 to en_US.UTF-8
> - Use exactly the same version of CMake as on CI: 3.6.3
> - Remove all extra software which is not on CI: python v3, Z3, cmake from
> Homebrew
> - Make sure python 2.x version is almost the same as on CI (Jenkins has
> 2.7.10, while I have 2.7.13, recently bumped to 2.7.14)
>
> - Checkout 100% identical source code as it is used by Jenkins
> For this one I checked build #354
> https://ci.swift.org/job/oss-swift-package-osx/354/parameters/ and made
> sure all submodules have identical commits.
> This is where I noticed that I was using latest ninja version 1.8.2, while
> Jenkins uses 1.7.2.
> I also noticed that llvm is build from 1 commit above the
> swift-DEVELOPMENT-SNAPSHOT-2017-09-25-a tag somehow... (418d91a243e)
>
> This one wasn't intentional, but I ended up trying to build 2017-09-25-a
> snapshot using 2017-09-25-a toolchain downloaded from swift.org.
>
> All of that lands me with the same 3 failing tests for iPhone 5 simulator.
>
> I know that I can work on code base without running the tests.
>
> But I really wanted to be able to build the toolchain and try it out in
> Xcode, especially since blog post on refactoring just says "Use
> build-toolchain script to build your own toolchain"...
>
>
> Quick update: I just checked my side machine. I was able to build
> everything successfully, pass tests, and build the package/toolchain for
> tag 'swift-DEVELOPMENT-SNAPSHOT-2017-09-18-a'.
>
> I am going to swing back and read the rest of this email later today. I
> need to finish a few things today.
>
> Michael
>
>
> Regards,
> Max
>
> On Wed, Sep 27, 2017 at 3:11 AM, Michael Gottesman <mgottesman at apple.com>
> wrote:
>
>> Ok. My side machine info:
>>
>> ```
>> $ sw_vers
>> ProductName: Mac OS X
>> ProductVersion: 10.12.6
>> BuildVersion: 16G26
>> $ xcodebuild -version
>> Xcode 9.0
>> Build version 9M214v
>> $ cmake --version
>> cmake version 3.8.2
>>
>> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>> $
>> ```
>>
>> So I think I should be able to reproduce since we have the same xcode/os
>> version. I am starting a build now.
>>
>> On Sep 26, 2017, at 9:44 AM, Michael Gottesman <mgottesman at apple.com>
>> wrote:
>>
>> Ok. I am looking at this now on my side machine.
>>
>> Sorry for the delay, I had to land code and then I had vacation = (.
>>
>> Michael
>>
>> On Sep 20, 2017, at 10:05 PM, Michael Gottesman via swift-dev <
>> swift-dev at swift.org> wrote:
>>
>> FYI, I haven't forgotten you! I just need to land some code tonight ; ).
>> I want to try to reproduce exactly what you are doing.
>>
>> Michael
>>
>> On Sep 20, 2017, at 6:08 AM, Maksym Grebenets <mgrebenets at gmail.com>
>> wrote:
>>
>> I tried few more options.
>>
>> I tried switching my shell to bash and giving it a go.
>> This time I got some unusual configuration error.
>> The error came
>> from /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPythonInterp.cmake.
>> Unfortunately the error message was in stderr, while I only captured
>> stdout:
>> https://gist.github.com/mgrebenets/bf3a54cb90141c17c715f5ddfddf6c04
>>
>> So then I added CMake.app bin to the path
>> export PATH=/Applications/CMake.app/Contents/bin:PATH
>> and ran the build again.
>> This time it didn't fail with configuration error, but failed with "too
>> many files open" and somehow still using cmake 3.9.2 from Homebrew
>> installation:
>> https://gist.github.com/mgrebenets/100cf995fbb9c5415a26e0968aa7ed58
>>
>> So finally, I decided to use CMake.app only:
>> brew unlink cmake
>> Run again, and same 3 tests fail on same i386 simulator:
>> https://gist.github.com/mgrebenets/cf722b3e19894e7cbeeb3c4fa6d2511e
>>
>> Regards,
>> Max
>>
>>
>>
>> On Wed, Sep 20, 2017 at 2:59 PM, Maksym Grebenets <mgrebenets at gmail.com>
>> wrote:
>>
>>> I see.
>>>
>>> I gave it another go:
>>> https://gist.github.com/mgrebenets/e2c981951586910c679df17d377c9e69
>>>
>>> Looking at the build logs, I can definitely see llvm source code being
>>> built.
>>> I've looked up a bunch of llvm .cpp files in the build log,
>>> e.g. LLVMTargetMachine.cpp.
>>> Unless I'm not looking in the right place.
>>>
>>> Still same 3 failures in the end.
>>>
>>> I have noticed that in certain places Jenkings builds are using
>>> /Applications/CMake.app, while on my machine it is
>>> */usr/local/Cellar/cmake/3.9.1/bin/cmake.*
>>> So I've tried to upgrade to 3.9.2 and run same test command manually -
>>> same failures.
>>> Same for using CMake.app downloaded from cmake.org (3.9.2) version.
>>>
>>> I've double checked python version that I have, it's 2.7.10, same as on
>>> Jenkins instances.
>>>
>>> I do have python3 installed in /usr/local/bin/python3, not sure if this
>>> could be related.
>>>
>>> Looking at the failing tests, it seems like all of them are related to
>>> encoding.
>>> The first one is related to Unicode 9 graphemes.
>>> For a string "🇺🇸🇨🇦🇩🇰🏳️‍🌈" the expected count is 4, while on my
>>> machine it's 5.
>>> Other failures are in CodableTests.swift, but all of them report an
>>> error like:
>>> Decoded URLComponents <//0.0.0.0> not equal to original <//0.0.0.0>
>>> I can't really spot the difference, unless there's some invisible escape
>>> character...
>>>
>>> Last failing test is for NSValue bridging:
>>> stdout>>> check failed at
>>> /Users/grebenma/Projects/oss/swift/swift/stdlib/private/StdlibUnittestFoundationExtras/StdlibUnittestFoundationExtras.swift,
>>> line 130
>>> stdout>>> expected: <00000000 00003140 00000000 00004340> (of type
>>> NSConcreteValue)
>>> stdout>>> actual: <00000000 00003140 00000000 00004340> (of type
>>> NSConcreteValue)
>>>
>>> It appears that all failures are for iPhone Simulator i386.
>>> So it must be related to 32-bit platforms only.
>>>
>>> I don't have much ideas on what it could be.
>>> Is it something set in my bash (zsh) profile?
>>> E.g. something in the path, or some 3rd party tool installed.
>>> Are there any hints in the log that may point me in the right direction?
>>>
>>> Thanks.
>>>
>>>
>>>
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170928/44566d1c/attachment.html>