Bug 1794306 - swift-lang-5.1.3-0.1.20191213git005fc1f.fc32: FTBFS with gcc 10: error: unknown type name 'uint8_t'
Summary: swift-lang-5.1.3-0.1.20191213git005fc1f.fc32: FTBFS with gcc 10: error: unkno...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: swift-lang
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ron Olson
QA Contact: Fedora Extras Quality Assurance
URL: https://koschei.fedoraproject.org/pac...
Whiteboard:
Depends On:
Blocks: F32FTBFS F33FTBFS PYTHON39 GCC10
TreeView+ depends on / blocked
 
Reported: 2020-01-23 09:02 UTC by Jitka Plesnikova
Modified: 2020-08-03 04:45 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-11 17:42:42 UTC
Type: Bug


Attachments (Terms of Use)

Description Jitka Plesnikova 2020-01-23 09:02:30 UTC
swift-lang-5.1.3-0.1.20191213git005fc1f.fc32 fails to build in F32:

/builddir/build/BUILD/swift-source/llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h:90:36: error: unknown type name 'uint8_t'
enum class IntrinsicFunctionKind : uint8_t {
                                   ^
/builddir/build/BUILD/swift-source/llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h:181:18: error: unknown type name 'uint16_t'
enum FuncClass : uint16_t {
                 ^
/builddir/build/BUILD/swift-source/llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h:239:8: error: no type named 'string' in namespace 'std'
  std::string toString(OutputFlags Flags = OF_Default) const;
  ~~~~~^

/builddir/build/BUILD/swift-source/llvm/lib/Demangle/MicrosoftDemangle.cpp:290:63: error: cannot initialize a parameter of type 'llvm::ms_demangle::IdentifierNode *' with an lvalue of type 'llvm::ms_demangle::LocalStaticGuardIdentifierNode *'
  QualifiedNameNode *QN = demangleNameScopeChain(MangledName, LSGI);
                                                              ^~~~
A difference between passing and failing build root is at 
https://koschei.fedoraproject.org/build/7748247
This is probably triggered with an upgrade of gcc from 9.2.1-1.fc32.3 to 10.0.1-0.3.fc32.

Additional info:
This package is tracked by Koschei. See:
https://koschei.fedoraproject.org/package/swift-lang

Comment 1 Ben Cotton 2020-02-11 17:27:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 2 Fedora Release Engineering 2020-02-16 04:33:30 UTC
Dear Maintainer,

your package has not been built successfully in 32. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
will be orphaned if this bug remains in NEW state more than 8 weeks.

A week before the mass branching of Fedora 33 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 31 will be
retired regardless of the status of this bug.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedoraproject.org/wiki/Releases/33/Schedule

Comment 3 Ron Olson 2020-02-16 16:11:30 UTC
Not sure where this is coming from; 5.1.4 was already released and fixes this issue: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1b5f3160ec

Comment 4 Miro Hrončok 2020-02-25 17:43:44 UTC
swift-lang-5.1.4-0.1.20200131git2194dc2.fc33 and swift-lang-5.2-0.7.20200219git998f2de.fc33 also fails according to https://koji.fedoraproject.org/koji/packageinfo?packageID=27252

This is blocking the Python 3.9 rebuild.

For the build logs with Python 3.9, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01251640-swift-lang/

For all our attempts to build swift-lang with Python 3.9, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/swift-lang/

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/

Let us know here if you have any questions.

Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon.
We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.

Comment 5 Ron Olson 2020-02-26 20:35:37 UTC
I think this is unrelated to Python 3.9 but an issue with something with Clang 10. I'm able to build everything successfully using 31, but neither 32 nor Rawhide. Note that I'm not working on 5.1.4 as it will presumably soon be superseded by 5.2 so that is the version I'm trying to get working.

Comment 6 Ron Olson 2020-02-28 02:21:14 UTC
So as an update, it builds fine in F32, but not in Rawhide; the version of Clang is the same, so not sure what the difference might be that is making the difference.

Comment 7 Ron Olson 2020-03-02 15:56:51 UTC
I think I've tracked it down to Rawhide having CMake 3.17.0-rc1 vs Fedora 32 having 3.16.4. I've had issues with CMake before (and they even made a version to fix one of my reported issues); still tracking down how it's getting triggered.

Comment 8 Ron Olson 2020-03-06 22:03:14 UTC
I tracked the issue down to a change in CMake 3.17, the specific issue is the addition of the 'config' entry here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmNinjaTargetGenerator.cxx#L963. If anyone is interested in my discussions with the Apple folks, that's here: https://forums.swift.org/t/building-libdispatch-on-linux-crashes/34319/5. 

Hopefully this can be worked out at the CMake level; the file that is causing the issue is not patchable insofar as it's generated as part of the build process.

Comment 9 Ron Olson 2020-04-11 17:42:42 UTC
Fixed in current release of CMake


Note You need to log in before you can comment on or make changes to this bug.