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 <mgottes...@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@swift.org <mailto:swift-dev@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 <mgreben...@gmail.com >>> <mailto:mgreben...@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 >>> <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 >>> <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 >>> <https://gist.github.com/mgrebenets/cf722b3e19894e7cbeeb3c4fa6d2511e> >>> >>> Regards, >>> Max >>> >>> >>> >>> On Wed, Sep 20, 2017 at 2:59 PM, Maksym Grebenets <mgreben...@gmail.com >>> <mailto:mgreben...@gmail.com>> wrote: >>> I see. >>> >>> I gave it another go: >>> https://gist.github.com/mgrebenets/e2c981951586910c679df17d377c9e69 >>> <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 <http://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 <http://0.0.0.0/>> not equal to original >>> <//0.0.0.0 <http://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@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
