Glibc.swift: error: no such module 'SwiftGlibc'

Eric_Wing · November 8, 2016, 3:51am

I am trying to build Swift for Android and I'm getting the error:
Glibc.swift:13:19: error: no such module 'SwiftGlibc'

I found several other posts asking about this problem for Linux, but
no solid resolution.

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160418/001741.html
https://www.mail-archive.com/swift-users@swift.org/msg02098.html
https://aur.archlinux.org/packages/swift-language-git/?comments=all

My problem is a little different. Besides the Android part, I should
mention a few other things:

- I am building Swift as ReleaseAssert under Steam-Runtime (which uses
clang 3.6.0), where I get the error.

- If I build as DebugAssert (Steam-Runtime), I do not see this problem
(and the build finished). I'm a little surprised debug worked but not
release.

- If I build under Ubuntu 16.10, I do not hit this problem (both debug
and release)

- I do not see any other error messages as stated in the other thread
like (ioctl.h not found). My error message is pretty unhelpful about
why it failed. (Pasted below)

- I looked for a glibc.modulemap for my broken build. I do not see any
in the build directory, nor does it exist on my system. (I do see it
created in the successful build.)

Anyway, I really could use some guidance on how to get around/fix this
problem. I want to use Steam-Runtime because I can build a Swift/Linux
compiler binary that I can run on most Linux distros, not just Ubuntu
16.10.

I appreciate any help.
Thanks,
Eric

cd /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform
&& /home/pinky/steam-runtime/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/android/armv7
&& /home/pinky/steam-runtime/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7
&& /home/pinky/Source/SWIFT/swift/utils/line-directive
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Glibc.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Platform.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/TiocConstants.swift
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift
-- /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./bin/swiftc
-c -sdk /home/pinky/Android/android-ndk/platforms/android-21/arch-arm
-target armv7-none-linux-androideabi -resource-dir
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift
-O -D INTERNAL_CHECKS_ENABLED -I
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7
-module-cache-path
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./module-cache
-no-link-objc-runtime -autolink-force-load -module-link-name
swiftGlibc -force-single-frontend-invocation -parse-as-library
-emit-module -emit-module-path
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/Glibc.swiftmodule
-o /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/android/armv7/Glibc.o
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Glibc.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Platform.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/TiocConstants.swift
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift

FAILED: stdlib/public/Platform/android/armv7/Glibc.o
lib/swift/android/armv7/Glibc.swiftmodule
lib/swift/android/armv7/Glibc.swiftdoc
cd /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform
&& /home/pinky/steam-runtime/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/android/armv7
&& /home/pinky/steam-runtime/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7
&& /home/pinky/Source/SWIFT/swift/utils/line-directive
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Glibc.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Platform.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/TiocConstants.swift
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift
-- /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./bin/swiftc
-c -sdk /home/pinky/Android/android-ndk/platforms/android-21/arch-arm
-target armv7-none-linux-androideabi -resource-dir
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift
-O -D INTERNAL_CHECKS_ENABLED -I
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7
-module-cache-path
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./module-cache
-no-link-objc-runtime -autolink-force-load -module-link-name
swiftGlibc -force-single-frontend-invocation -parse-as-library
-emit-module -emit-module-path
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/Glibc.swiftmodule
-o /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/android/armv7/Glibc.o
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Glibc.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Platform.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/TiocConstants.swift
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift
/home/pinky/Source/SWIFT/swift/stdlib/public/Platform/Glibc.swift:13:19:
error: no such module 'SwiftGlibc'
@_exported import SwiftGlibc // Clang module

Eric_Wing · November 9, 2016, 7:40am

I'm comparing the build log differences between the successful build
on Ubuntu 16.10 and the failed build in Steam-Runtime.

It looks like while building Swift (past llvm & clang), at step
[651/720], the build logs diverge.
In the successful case on Ubuntu, the command is building
glibc.modulemap. But in the failed case, it seems to skip this, and is
building tgmath.swift.tmp. The build ultimately fails at step 653,
failing to find SwiftGlibc.

Any ideas why the build system would be skipping the glibc.modulemap
step in the bad case?

Below are the two steps.

Bad (steamrt):
[651/720] cd /home/pinky/Source/SWIFT/swift/stdlib/public/Platform &&
/home/pinky/steam-runtime/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4
&& /home/pinky/Source/SWIFT/swift/utils/gyb
-DunicodeGraphemeBreakPropertyFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=4 -o
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift.tmp
tgmath.swift.gyb && /home/pinky/steam-runtime/usr/bin/cmake -E
copy_if_different
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift.tmp
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift
&& /home/pinky/steam-runtime/usr/bin/cmake -E remove
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift.tmp

Good (Ubuntu):
[651/720] cd /home/pinky/Source/SWIFT/swift/stdlib/public/Platform &&
/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7
&& /home/pinky/Source/SWIFT/swift/utils/gyb
-DunicodeGraphemeBreakPropertyFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SDK=ANDROID
-DGLIBC_INCLUDE_PATH=/home/pinky/Android/android-ndk/platforms/android-21/arch-arm//usr/include
-DGLIBC_ARCH_INCLUDE_PATH=/home/pinky/Android/android-ndk/platforms/android-21/arch-arm//usr/include
-o /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap.tmp
glibc.modulemap.gyb && /usr/bin/cmake -E copy_if_different
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap.tmp
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap
&& /usr/bin/cmake -E remove
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap.tmp

jrose · November 9, 2016, 4:50pm

Ah, that does help. The logic to build the Glibc module map comes from stdlib/public/Platform/CMakeLists.txt, and explicitly checks for “LINUX”, “FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a different SDK name?

Jordan

···

On Nov 8, 2016, at 23:40, Eric Wing via swift-dev <swift-dev@swift.org> wrote:

I'm comparing the build log differences between the successful build
on Ubuntu 16.10 and the failed build in Steam-Runtime.

It looks like while building Swift (past llvm & clang), at step
[651/720], the build logs diverge.
In the successful case on Ubuntu, the command is building
glibc.modulemap. But in the failed case, it seems to skip this, and is
building tgmath.swift.tmp. The build ultimately fails at step 653,
failing to find SwiftGlibc.

Any ideas why the build system would be skipping the glibc.modulemap
step in the bad case?

Below are the two steps.

Bad (steamrt):
[651/720] cd /home/pinky/Source/SWIFT/swift/stdlib/public/Platform &&
/home/pinky/steam-runtime/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4
&& /home/pinky/Source/SWIFT/swift/utils/gyb
-DunicodeGraphemeBreakPropertyFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SIZEOF_VOID_P=4 -o
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift.tmp
tgmath.swift.gyb && /home/pinky/steam-runtime/usr/bin/cmake -E
copy_if_different
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift.tmp
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift
&& /home/pinky/steam-runtime/usr/bin/cmake -E remove
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/4/tgmath.swift.tmp

Good (Ubuntu):
[651/720] cd /home/pinky/Source/SWIFT/swift/stdlib/public/Platform &&
/usr/bin/cmake -E make_directory
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7
&& /home/pinky/Source/SWIFT/swift/utils/gyb
-DunicodeGraphemeBreakPropertyFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakProperty.txt
-DunicodeGraphemeBreakTestFile=/home/pinky/Source/SWIFT/swift/utils/UnicodeData/GraphemeBreakTest.txt
-DCMAKE_SDK=ANDROID
-DGLIBC_INCLUDE_PATH=/home/pinky/Android/android-ndk/platforms/android-21/arch-arm//usr/include
-DGLIBC_ARCH_INCLUDE_PATH=/home/pinky/Android/android-ndk/platforms/android-21/arch-arm//usr/include
-o /home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap.tmp
glibc.modulemap.gyb && /usr/bin/cmake -E copy_if_different
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap.tmp
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap
&& /usr/bin/cmake -E remove
/home/pinky/Source/SWIFT/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/android/armv7/glibc.modulemap.tmp
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Eric_Wing · November 9, 2016, 9:41pm

How would I verify/debug this for sure? I haven't been setting
anything differently when I build under Steam-Runtime vs. Ubuntu. (And
I have gotten through a pure Linux (no Android) build under
Steam-Runtime successfully.) Steam-Runtime is just a Linux. (It is
originally derived from Ubuntu 12.04LTS, though it probably has all
its Ubuntu identifiers stripped/replaced.)

I checked the CMakeCache.txt in build/Ninja-ReleaseAssert/swift-linux-x86_64

Both files are identical between the Steam-Runtime and Ubuntu versions
when building for Android. The variable SWIFT_SDKS is:
SWIFT_SDKS:STRING=ANDROID;LINUX

Obviously something is different somewhere since it seems to be
skipping the glibc.modulemap in the Steam-Runtime case.

Thanks,
Eric

···

On 11/9/16, Jordan Rose <jordan_rose@apple.com> wrote:

Ah, that does help. The logic to build the Glibc module map comes from
stdlib/public/Platform/CMakeLists.txt, and explicitly checks for “LINUX”,
“FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a
different SDK name?

Jordan

Eric_Wing · November 9, 2016, 10:25pm

Oops. Correction to my last post. The CMakeCache.txt are not
identical. I compared the wrong files.

However, the SWIFT_SDKS variable are the same in each.

Here are some differences I did spot:

In Ubuntu, LIBXML2_XMLLINT_EXECUABLE is not found, but defined in my
SteamRT cache.

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=1
Steam
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=0
Steam:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=FAILED_TO_RUN

The remaining of the differences are tool version differences and
stuff with libICU (because Steam-Runtime doesn't supply it so I must
build/supply it myself). But most of these differences are expected.

Thanks,
Eric

···

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Jordan Rose <jordan_rose@apple.com> wrote:

Ah, that does help. The logic to build the Glibc module map comes from
stdlib/public/Platform/CMakeLists.txt, and explicitly checks for “LINUX”,
“FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a
different SDK name?

Jordan

How would I verify/debug this for sure? I haven't been setting
anything differently when I build under Steam-Runtime vs. Ubuntu. (And
I have gotten through a pure Linux (no Android) build under
Steam-Runtime successfully.) Steam-Runtime is just a Linux. (It is
originally derived from Ubuntu 12.04LTS, though it probably has all
its Ubuntu identifiers stripped/replaced.)

I checked the CMakeCache.txt in
build/Ninja-ReleaseAssert/swift-linux-x86_64

Both files are identical between the Steam-Runtime and Ubuntu versions
when building for Android. The variable SWIFT_SDKS is:
SWIFT_SDKS:STRING=ANDROID;LINUX

Obviously something is different somewhere since it seems to be
skipping the glibc.modulemap in the Steam-Runtime case.

Thanks,
Eric

Eric_Wing · November 10, 2016, 9:34pm

It looks like the problem is related to which version of CMake you use.

Ubuntu 16.10 supplies CMake 3.5.2.
Steam-Runtime ships a version that is way too old, so I built and used
the latest stable CMake version, 3.6.3.

Using 3.6.3 seems to always trigger this problem with the Swift build.

I tested it both ways:

1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
exactly the same way I described.

2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build completed.

I still don’t know specifically what the build script bug is. This is
going to need to be fixed eventually if all newer versions of CMake
lead to a broken build process.

Thanks,
Eric

···

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Jordan Rose <jordan_rose@apple.com> wrote:

Ah, that does help. The logic to build the Glibc module map comes from
stdlib/public/Platform/CMakeLists.txt, and explicitly checks for
“LINUX”,
“FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a
different SDK name?

Jordan

How would I verify/debug this for sure? I haven't been setting
anything differently when I build under Steam-Runtime vs. Ubuntu. (And
I have gotten through a pure Linux (no Android) build under
Steam-Runtime successfully.) Steam-Runtime is just a Linux. (It is
originally derived from Ubuntu 12.04LTS, though it probably has all
its Ubuntu identifiers stripped/replaced.)

I checked the CMakeCache.txt in
build/Ninja-ReleaseAssert/swift-linux-x86_64

Both files are identical between the Steam-Runtime and Ubuntu versions
when building for Android. The variable SWIFT_SDKS is:
SWIFT_SDKS:STRING=ANDROID;LINUX

Obviously something is different somewhere since it seems to be
skipping the glibc.modulemap in the Steam-Runtime case.

Thanks,
Eric

Oops. Correction to my last post. The CMakeCache.txt are not
identical. I compared the wrong files.

However, the SWIFT_SDKS variable are the same in each.

Here are some differences I did spot:

In Ubuntu, LIBXML2_XMLLINT_EXECUABLE is not found, but defined in my
SteamRT cache.

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=1
Steam
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=0
Steam:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=FAILED_TO_RUN

The remaining of the differences are tool version differences and
stuff with libICU (because Steam-Runtime doesn't supply it so I must
build/supply it myself). But most of these differences are expected.

Thanks,
Eric

William_Dillon2 · November 10, 2016, 10:20pm

Thanks so much for getting to the bottom of this!

I was getting by with hacks to get around this for a while. I'm very glad we have a reproducible change that triggers.

- Will

Ah, that does help. The logic to build the Glibc module map comes from
stdlib/public/Platform/CMakeLists.txt, and explicitly checks for
“LINUX”,
“FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a
different SDK name?

Jordan

How would I verify/debug this for sure? I haven't been setting
anything differently when I build under Steam-Runtime vs. Ubuntu. (And
I have gotten through a pure Linux (no Android) build under
Steam-Runtime successfully.) Steam-Runtime is just a Linux. (It is
originally derived from Ubuntu 12.04LTS, though it probably has all
its Ubuntu identifiers stripped/replaced.)

I checked the CMakeCache.txt in
build/Ninja-ReleaseAssert/swift-linux-x86_64

Both files are identical between the Steam-Runtime and Ubuntu versions
when building for Android. The variable SWIFT_SDKS is:
SWIFT_SDKS:STRING=ANDROID;LINUX

Obviously something is different somewhere since it seems to be
skipping the glibc.modulemap in the Steam-Runtime case.

Thanks,
Eric

Oops. Correction to my last post. The CMakeCache.txt are not
identical. I compared the wrong files.

However, the SWIFT_SDKS variable are the same in each.

Here are some differences I did spot:

In Ubuntu, LIBXML2_XMLLINT_EXECUABLE is not found, but defined in my
SteamRT cache.

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=1
Steam
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=0
Steam:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=FAILED_TO_RUN

The remaining of the differences are tool version differences and
stuff with libICU (because Steam-Runtime doesn't supply it so I must
build/supply it myself). But most of these differences are expected.

Thanks,
Eric

It looks like the problem is related to which version of CMake you use.

Ubuntu 16.10 supplies CMake 3.5.2.
Steam-Runtime ships a version that is way too old, so I built and used
the latest stable CMake version, 3.6.3.

Using 3.6.3 seems to always trigger this problem with the Swift build.

I tested it both ways:

1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
exactly the same way I described.

2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build completed.

I still don’t know specifically what the build script bug is. This is
going to need to be fixed eventually if all newer versions of CMake
lead to a broken build process.

Thanks,
Eric

···

On November 10, 2016 at 1:34:27 PM, Eric Wing via swift-dev (swift-dev@swift.org) wrote:
On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Jordan Rose <jordan_rose@apple.com> wrote:

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

jrose · November 10, 2016, 10:52pm

Nice job tracking this down! I can’t reproduce it with CMake 3.6.3 on Ubuntu 16.04 with a default configuration, though—or at least, I still see the glibc.modulemap target being generated in the Ninja file and listed as a dependency. Can you include your full build-script invocation line?

Jordan

···

On Nov 10, 2016, at 13:34, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Jordan Rose <jordan_rose@apple.com> wrote:

Ah, that does help. The logic to build the Glibc module map comes from
stdlib/public/Platform/CMakeLists.txt, and explicitly checks for
“LINUX”,
“FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a
different SDK name?

Jordan

How would I verify/debug this for sure? I haven't been setting
anything differently when I build under Steam-Runtime vs. Ubuntu. (And
I have gotten through a pure Linux (no Android) build under
Steam-Runtime successfully.) Steam-Runtime is just a Linux. (It is
originally derived from Ubuntu 12.04LTS, though it probably has all
its Ubuntu identifiers stripped/replaced.)

I checked the CMakeCache.txt in
build/Ninja-ReleaseAssert/swift-linux-x86_64

Both files are identical between the Steam-Runtime and Ubuntu versions
when building for Android. The variable SWIFT_SDKS is:
SWIFT_SDKS:STRING=ANDROID;LINUX

Obviously something is different somewhere since it seems to be
skipping the glibc.modulemap in the Steam-Runtime case.

Thanks,
Eric

Oops. Correction to my last post. The CMakeCache.txt are not
identical. I compared the wrong files.

However, the SWIFT_SDKS variable are the same in each.

Here are some differences I did spot:

In Ubuntu, LIBXML2_XMLLINT_EXECUABLE is not found, but defined in my
SteamRT cache.

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=1
Steam
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=0
Steam:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=FAILED_TO_RUN

The remaining of the differences are tool version differences and
stuff with libICU (because Steam-Runtime doesn't supply it so I must
build/supply it myself). But most of these differences are expected.

Thanks,
Eric

It looks like the problem is related to which version of CMake you use.

Ubuntu 16.10 supplies CMake 3.5.2.
Steam-Runtime ships a version that is way too old, so I built and used
the latest stable CMake version, 3.6.3.

Using 3.6.3 seems to always trigger this problem with the Swift build.

I tested it both ways:

1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
exactly the same way I described.

2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build completed.

I still don’t know specifically what the build script bug is. This is
going to need to be fixed eventually if all newer versions of CMake
lead to a broken build process.

willstanton · November 16, 2016, 5:05am

Hello Eric,

Wanted to share I ran into a similar/the same error message this week rebuilding from scratch (clean build/ on AWS Linux like CentOS): the build stops (almost certainly) because the native SwiftGlibc module isn’t generated. It happens near the end of the Swift build, around step 600/640ish.
I’m not sure if there is one cause, since others posting online have run into this message over the last year seemingly for different reasons (missing libraries?).

Anyway I was able to get past it by executing:
ninja make lib-swift-linux-x86_64-glibc.modulemap

Re-invoking the build script gave me this:
[1/1] Generating glibc.modulemap from glibc.modulemap.gyb

And the rest of the build went on its way. Maybe it’ll work for you if you're still seeing the problem?

I’ve filed SR-3219 [SR-3219] swiftGlibc build order wrong(?) · Issue #45807 · apple/swift · GitHub with my build.ninja in case it’s related to build order (alas I’m not too familiar with everything so I don’t know when SwiftGlibc is expected).

The error I came across:
[1/51] Compiling /home/ec2-user/swift/...b/public/Platform/linux/x86_64/Glibc.o
FAILED: stdlib/public/Platform/linux/x86_64/Glibc.o
cd /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform && /home/ec2-user/swift/swift/utils/line-directive /home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift /home/ec2-user/swift/swift/stdlib/public/Platform/Platform.swift /home/ec2-user/swift/swift/stdlib/public/Platform/TiocConstants.swift /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/8/tgmath.swift -- /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./bin/swiftc -c -sdk / -target x86_64-unknown-linux-gnu -resource-dir /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift -O -D INTERNAL_CHECKS_ENABLED -I /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/linux/x86_64 -module-cache-path /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./module-cache -no-link-objc-runtime -autolink-force-load -module-link-name swiftGlibc -force-single-frontend-invocation -parse-as-library -o /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/linux/x86_64/Glibc.o /home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift /home/ec2-user/swift/swift/stdlib/public/Platform/Platform.swift /home/ec2-user/swift/swift/stdlib/public/Platform/TiocConstants.swift /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/8/tgmath.swift
/home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift:13:19: error: no such module 'SwiftGlibc'
@_exported import SwiftGlibc // Clang module
^

Regards,
Will Stanton

···

On Nov 10, 2016, at 4:34 PM, Eric Wing via swift-dev <swift-dev@swift.org> wrote:

Ubuntu 16.10 supplies CMake 3.5.2.
Steam-Runtime ships a version that is way too old, so I built and used
the latest stable CMake version, 3.6.3.

Using 3.6.3 seems to always trigger this problem with the Swift build.

I tested it both ways:

1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
exactly the same way I described.

2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build completed.

Eric_Wing · November 10, 2016, 11:16pm

Ah, that does help. The logic to build the Glibc module map comes from
stdlib/public/Platform/CMakeLists.txt, and explicitly checks for
“LINUX”,
“FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a
different SDK name?

Jordan

How would I verify/debug this for sure? I haven't been setting
anything differently when I build under Steam-Runtime vs. Ubuntu. (And
I have gotten through a pure Linux (no Android) build under
Steam-Runtime successfully.) Steam-Runtime is just a Linux. (It is
originally derived from Ubuntu 12.04LTS, though it probably has all
its Ubuntu identifiers stripped/replaced.)

I checked the CMakeCache.txt in
build/Ninja-ReleaseAssert/swift-linux-x86_64

Both files are identical between the Steam-Runtime and Ubuntu versions
when building for Android. The variable SWIFT_SDKS is:
SWIFT_SDKS:STRING=ANDROID;LINUX

Obviously something is different somewhere since it seems to be
skipping the glibc.modulemap in the Steam-Runtime case.

Thanks,
Eric

Oops. Correction to my last post. The CMakeCache.txt are not
identical. I compared the wrong files.

However, the SWIFT_SDKS variable are the same in each.

Here are some differences I did spot:

In Ubuntu, LIBXML2_XMLLINT_EXECUABLE is not found, but defined in my
SteamRT cache.

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=1
Steam
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=0
Steam:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=FAILED_TO_RUN

The remaining of the differences are tool version differences and
stuff with libICU (because Steam-Runtime doesn't supply it so I must
build/supply it myself). But most of these differences are expected.

Thanks,
Eric

It looks like the problem is related to which version of CMake you use.

Ubuntu 16.10 supplies CMake 3.5.2.
Steam-Runtime ships a version that is way too old, so I built and used
the latest stable CMake version, 3.6.3.

Using 3.6.3 seems to always trigger this problem with the Swift build.

I tested it both ways:

1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
exactly the same way I described.

2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build
completed.

I still don’t know specifically what the build script bug is. This is
going to need to be fixed eventually if all newer versions of CMake
lead to a broken build process.

Nice job tracking this down! I can’t reproduce it with CMake 3.6.3 on Ubuntu
16.04 with a default configuration, though—or at least, I still see the
glibc.modulemap target being generated in the Ninja file and listed as a
dependency. Can you include your full build-script invocation line?

Jordan

My PATH is modified to make sure to use my built version of CMake
instead of the system one.

./swift/utils/build-script --release --skip-test-linux --android
--android-ndk=/home/pinky/Android/android-ndk --android-api-level=21
--android-icu-uc
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/lib/libicuucswift.so
--android-icu-uc-include
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/include
--android-icu-i18n
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/lib/libicui18nswift.so
--android-icu-i18n-include
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/include/
--extra-cmake-options="-DCMAKE_VERBOSE_MAKEFILE=1"

The top of my git log is:

commit 7a3a1e3697e104522734aaea62987e6ef7d58e79
Merge: 23525d9 9577d98
Author: swift-ci <swift-ci@users.noreply.github.com>

Merge pull request #5500 from nkcsgexi/closure

···

On 11/10/16, Jordan Rose <jordan_rose@apple.com> wrote:

On Nov 10, 2016, at 13:34, Eric Wing <ewmailing@gmail.com> wrote:
On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Jordan Rose <jordan_rose@apple.com> wrote:

Date: Thu Oct 27 13:43:11 2016 -0700

Eric_Wing · November 19, 2016, 4:57am

Interesting...following your suggestion, also doing:

ninja make lib-swift-android-armv7-glibc.modulemap

and then resuming the normal build got me through the rest of the
build with CMake 3.6.3.

(To your other email,
Android is technically Bionic instead of Glibc, but the Swift build
system is pretending they are the same. This may need to be addressed
in the future...)

Thanks,
Eric

···

On 11/15/16, Will Stanton <willstanton1@yahoo.com> wrote:

Hello Eric,

Wanted to share I ran into a similar/the same error message this week
rebuilding from scratch (clean build/ on AWS Linux like CentOS): the build
stops (almost certainly) because the native SwiftGlibc module isn’t
generated. It happens near the end of the Swift build, around step
600/640ish.
I’m not sure if there is one cause, since others posting online have run
into this message over the last year seemingly for different reasons
(missing libraries?).

Anyway I was able to get past it by executing:
ninja make lib-swift-linux-x86_64-glibc.modulemap

Re-invoking the build script gave me this:
[1/1] Generating glibc.modulemap from glibc.modulemap.gyb

And the rest of the build went on its way. Maybe it’ll work for you if
you're still seeing the problem?

I’ve filed SR-3219 [SR-3219] swiftGlibc build order wrong(?) · Issue #45807 · apple/swift · GitHub with my build.ninja
in case it’s related to build order (alas I’m not too familiar with
everything so I don’t know when SwiftGlibc is expected).

The error I came across:
[1/51] Compiling
/home/ec2-user/swift/...b/public/Platform/linux/x86_64/Glibc.o
FAILED: stdlib/public/Platform/linux/x86_64/Glibc.o
cd
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform
&& /home/ec2-user/swift/swift/utils/line-directive
/home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift
/home/ec2-user/swift/swift/stdlib/public/Platform/Platform.swift
/home/ec2-user/swift/swift/stdlib/public/Platform/TiocConstants.swift
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/8/tgmath.swift
--
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./bin/swiftc
-c -sdk / -target x86_64-unknown-linux-gnu -resource-dir
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift
-O -D INTERNAL_CHECKS_ENABLED -I
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./lib/swift/linux/x86_64
-module-cache-path
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/./module-cache
-no-link-objc-runtime -autolink-force-load -module-link-name swiftGlibc
-force-single-frontend-invocation -parse-as-library -o
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/linux/x86_64/Glibc.o
/home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift
/home/ec2-user/swift/swift/stdlib/public/Platform/Platform.swift
/home/ec2-user/swift/swift/stdlib/public/Platform/TiocConstants.swift
/home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/stdlib/public/Platform/8/tgmath.swift
/home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift:13:19: error:
no such module 'SwiftGlibc'
@_exported import SwiftGlibc // Clang module
^

Regards,
Will Stanton

On Nov 10, 2016, at 4:34 PM, Eric Wing via swift-dev <swift-dev@swift.org> >> wrote:

Ubuntu 16.10 supplies CMake 3.5.2.
Steam-Runtime ships a version that is way too old, so I built and used
the latest stable CMake version, 3.6.3.

Using 3.6.3 seems to always trigger this problem with the Swift build.

I tested it both ways:

1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
exactly the same way I described.

2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build
completed.

jrose · November 10, 2016, 11:23pm

Aha, even in your "on Ubuntu" build it's still a cross build for Android. In that case I'm not set up to reproduce it at the moment.

Adding Brian, who unofficially owns the unofficial Android build support. It's a spare time project for him, though, so I don't know if he'll be able to respond.

Jordan

···

On Nov 10, 2016, at 15:16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/10/16, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

On Nov 10, 2016, at 13:34, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Eric Wing <ewmailing@gmail.com> wrote:

On 11/9/16, Jordan Rose <jordan_rose@apple.com> wrote:

Ah, that does help. The logic to build the Glibc module map comes from
stdlib/public/Platform/CMakeLists.txt, and explicitly checks for
“LINUX”,
“FREEBSD”, “ANDROID”, and “CYGWIN”. Does the Steam-Runtime build use a
different SDK name?

Jordan

How would I verify/debug this for sure? I haven't been setting
anything differently when I build under Steam-Runtime vs. Ubuntu. (And
I have gotten through a pure Linux (no Android) build under
Steam-Runtime successfully.) Steam-Runtime is just a Linux. (It is
originally derived from Ubuntu 12.04LTS, though it probably has all
its Ubuntu identifiers stripped/replaced.)

I checked the CMakeCache.txt in
build/Ninja-ReleaseAssert/swift-linux-x86_64

Both files are identical between the Steam-Runtime and Ubuntu versions
when building for Android. The variable SWIFT_SDKS is:
SWIFT_SDKS:STRING=ANDROID;LINUX

Obviously something is different somewhere since it seems to be
skipping the glibc.modulemap in the Steam-Runtime case.

Thanks,
Eric

Oops. Correction to my last post. The CMakeCache.txt are not
identical. I compared the wrong files.

However, the SWIFT_SDKS variable are the same in each.

Here are some differences I did spot:

In Ubuntu, LIBXML2_XMLLINT_EXECUABLE is not found, but defined in my
SteamRT cache.

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=1
Steam
SWIFT_HAVE_WORKING_STD_REGEX_TEST:INTERNAL=

Ubuntu:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=0
Steam:
SWIFT_HAVE_WORKING_STD_REGEX_TEST_EXITCODE:INTERNAL=FAILED_TO_RUN

The remaining of the differences are tool version differences and
stuff with libICU (because Steam-Runtime doesn't supply it so I must
build/supply it myself). But most of these differences are expected.

Thanks,
Eric

It looks like the problem is related to which version of CMake you use.

Ubuntu 16.10 supplies CMake 3.5.2.
Steam-Runtime ships a version that is way too old, so I built and used
the latest stable CMake version, 3.6.3.

Using 3.6.3 seems to always trigger this problem with the Swift build.

I tested it both ways:

1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
exactly the same way I described.

2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build
completed.

I still don’t know specifically what the build script bug is. This is
going to need to be fixed eventually if all newer versions of CMake
lead to a broken build process.

Nice job tracking this down! I can’t reproduce it with CMake 3.6.3 on Ubuntu
16.04 with a default configuration, though—or at least, I still see the
glibc.modulemap target being generated in the Ninja file and listed as a
dependency. Can you include your full build-script invocation line?

Jordan

My PATH is modified to make sure to use my built version of CMake
instead of the system one.

./swift/utils/build-script --release --skip-test-linux --android
--android-ndk=/home/pinky/Android/android-ndk --android-api-level=21
--android-icu-uc
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/lib/libicuucswift.so
--android-icu-uc-include
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/include
--android-icu-i18n
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/lib/libicui18nswift.so
--android-icu-i18n-include
/home/pinky/Source/SWIFTANDROID/libiconv-libicu-android/armeabi-v7a/include/
--extra-cmake-options="-DCMAKE_VERBOSE_MAKEFILE=1"

The top of my git log is:

commit 7a3a1e3697e104522734aaea62987e6ef7d58e79
Merge: 23525d9 9577d98
Author: swift-ci <swift-ci@users.noreply.github.com <mailto:swift-ci@users.noreply.github.com>>
Date: Thu Oct 27 13:43:11 2016 -0700

Merge pull request #5500 from nkcsgexi/closure

rintaro · November 21, 2016, 5:37am

Hi Eric,

[SR-3219] swiftGlibc build order wrong(?) · Issue #45807 · apple/swift · GitHub has been resolved.
The current master branch still reproduce the problem? If so, could you
open a new SR and share the generated build.ninja file in the build
directory?

···

2016-11-19 13:57 GMT+09:00 Eric Wing via swift-dev <swift-dev@swift.org>:

On 11/15/16, Will Stanton <willstanton1@yahoo.com> wrote:
> Hello Eric,
>
> Wanted to share I ran into a similar/the same error message this week
> rebuilding from scratch (clean build/ on AWS Linux like CentOS): the
build
> stops (almost certainly) because the native SwiftGlibc module isn’t
> generated. It happens near the end of the Swift build, around step
> 600/640ish.
> I’m not sure if there is one cause, since others posting online have run
> into this message over the last year seemingly for different reasons
> (missing libraries?).
>
>
> Anyway I was able to get past it by executing:
> ninja make lib-swift-linux-x86_64-glibc.modulemap
>
> Re-invoking the build script gave me this:
> [1/1] Generating glibc.modulemap from glibc.modulemap.gyb
>
> And the rest of the build went on its way. Maybe it’ll work for you if
> you're still seeing the problem?
>
> I’ve filed SR-3219 [SR-3219] swiftGlibc build order wrong(?) · Issue #45807 · apple/swift · GitHub with my
build.ninja
> in case it’s related to build order (alas I’m not too familiar with
> everything so I don’t know when SwiftGlibc is expected).
>
> The error I came across:
> [1/51] Compiling
> /home/ec2-user/swift/...b/public/Platform/linux/x86_64/Glibc.o
> FAILED: stdlib/public/Platform/linux/x86_64/Glibc.o
> cd
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/stdlib/public/Platform
> && /home/ec2-user/swift/swift/utils/line-directive
> /home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift
> /home/ec2-user/swift/swift/stdlib/public/Platform/Platform.swift
> /home/ec2-user/swift/swift/stdlib/public/Platform/TiocConstants.swift
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/stdlib/public/Platform/8/tgmath.swift
> --
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/./bin/swiftc
> -c -sdk / -target x86_64-unknown-linux-gnu -resource-dir
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/./lib/swift
> -O -D INTERNAL_CHECKS_ENABLED -I
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/./lib/swift/linux/x86_64
> -module-cache-path
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/./module-cache
> -no-link-objc-runtime -autolink-force-load -module-link-name swiftGlibc
> -force-single-frontend-invocation -parse-as-library -o
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/stdlib/public/Platform/linux/x86_64/Glibc.o
> /home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift
> /home/ec2-user/swift/swift/stdlib/public/Platform/Platform.swift
> /home/ec2-user/swift/swift/stdlib/public/Platform/TiocConstants.swift
> /home/ec2-user/swift/build/Ninja-ReleaseAssert/swift-
linux-x86_64/stdlib/public/Platform/8/tgmath.swift
> /home/ec2-user/swift/swift/stdlib/public/Platform/Glibc.swift:13:19:
error:
> no such module 'SwiftGlibc'
> @_exported import SwiftGlibc // Clang module
> ^
>
>
>
> Regards,
> Will Stanton
>
>> On Nov 10, 2016, at 4:34 PM, Eric Wing via swift-dev < > swift-dev@swift.org> > >> wrote:
>>
>> Ubuntu 16.10 supplies CMake 3.5.2.
>> Steam-Runtime ships a version that is way too old, so I built and used
>> the latest stable CMake version, 3.6.3.
>>
>> Using 3.6.3 seems to always trigger this problem with the Swift build.
>>
>> I tested it both ways:
>>
>> 1. I changed Ubuntu 16.10 to use CMake 3.6.3 and the build broke in
>> exactly the same way I described.
>>
>> 2. In Steam-Runtime, I built/used CMake 3.5.2 instead, and the build
>> completed.
>
>

Interesting...following your suggestion, also doing:

ninja make lib-swift-android-armv7-glibc.modulemap

and then resuming the normal build got me through the rest of the
build with CMake 3.6.3.

(To your other email,
Android is technically Bionic instead of Glibc, but the Swift build
system is pretending they are the same. This may need to be addressed
in the future...)

Thanks,
Eric
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Eric_Wing · November 22, 2016, 12:33am

This appears to have fixed the problem.

Thanks,
Eric

···

On 11/20/16, rintaro ishizaki <fs.output@gmail.com> wrote:

Hi Eric,

[SR-3219] swiftGlibc build order wrong(?) · Issue #45807 · apple/swift · GitHub has been resolved.
The current master branch still reproduce the problem? If so, could you
open a new SR and share the generated build.ninja file in the build
directory?