Bug 1675396 - mmapper: FTBFS in Fedora rawhide/f30
Summary: mmapper: FTBFS in Fedora rawhide/f30
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mmapper
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1713865
Blocks: F30FTBFS
TreeView+ depends on / blocked
 
Reported: 2019-02-11 20:53 UTC by Fedora Release Engineering
Modified: 2019-05-25 09:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-26 18:53:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (1.00 KB, text/plain)
2019-02-11 20:53 UTC, Fedora Release Engineering
no flags Details
root.log (1.00 KB, text/plain)
2019-02-11 20:53 UTC, Fedora Release Engineering
no flags Details
state.log (621 bytes, text/plain)
2019-02-11 20:53 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2019-02-11 20:53:43 UTC
mmapper failed to build from source in Fedora rawhide/f30

https://koji.fedoraproject.org/koji/taskinfo?taskID=32414876


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
Please fix mmapper at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
mmapper will be orphaned. Before branching of Fedora 31,
mmapper will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://fedoraproject.org/wiki/Fails_to_build_from_source

Comment 1 Fedora Release Engineering 2019-02-11 20:53:45 UTC
Created attachment 1531281 [details]
build.log

file build.log too big, will only attach last 1024 bytes

Comment 2 Fedora Release Engineering 2019-02-11 20:53:47 UTC
Created attachment 1531282 [details]
root.log

file root.log too big, will only attach last 1024 bytes

Comment 3 Fedora Release Engineering 2019-02-11 20:53:48 UTC
Created attachment 1531283 [details]
state.log

Comment 4 Kalev Lember 2019-03-29 15:37:57 UTC
This regressed with gcc 9 and the build now errors out with "requested alignment is not an integer constant".

Jakub, any ideas if it's something that regressed in gcc? I don't really understand what alignas is supposed to do there. (It's a fringe package and not at all a priority for me if you are busy with something else.)

BUILDSTDERR: In file included from /builddir/build/BUILD/MMapper-2.7.4/src/expandoracommon/../mapdata/mmapper2exit.h:32,
BUILDSTDERR:                  from /builddir/build/BUILD/MMapper-2.7.4/src/expandoracommon/parseevent.h:42,
BUILDSTDERR:                  from /builddir/build/BUILD/MMapper-2.7.4/src/expandoracommon/parseevent.cpp:26:
BUILDSTDERR: /builddir/build/BUILD/MMapper-2.7.4/src/expandoracommon/../mapdata/ExitFieldVariant.h:64:59: error: requested alignment is not an integer constant
BUILDSTDERR:    64 |     alignas(STORAGE_ALIGNMENT) char storage[STORAGE_SIZE]{};
BUILDSTDERR:       |                                                           ^
BUILDSTDERR: make[2]: *** [tests/CMakeFiles/TestParser.dir/build.make:118: tests/CMakeFiles/TestParser.dir/__/src/expandoracommon/parseevent.cpp.o] Error 1

Comment 5 Marek Polacek 2019-03-29 15:40:47 UTC
How is STORAGE_ALIGNMENT defined?  It should be fairly easy to bisect it then.

Comment 6 Kalev Lember 2019-03-29 16:08:56 UTC
    static constexpr const size_t STORAGE_ALIGNMENT = std::max(alignof(DoorName),
                                                               std::max(alignof(ExitFlags),
                                                                        alignof(DoorFlags)));

And then DoorName is:

using DoorName = QString;

ExitFlags is:

class ExitFlags final : public enums::Flags<ExitFlags, ExitFlag, uint16_t>
{
public:
    using Flags::Flags;

public:
#define X_DEFINE_ACCESSORS(UPPER_CASE, lower_case, CamelCase, friendly) \
    bool is##CamelCase() const { return contains(ExitFlag::UPPER_CASE); }
    X_FOREACH_EXIT_FLAG(X_DEFINE_ACCESSORS)
#undef X_DEFINE_ACCESSORS
};

inline constexpr const ExitFlags operator|(ExitFlag lhs, ExitFlag rhs) noexcept
{
    return ExitFlags{lhs} | ExitFlags{rhs};
}

and finally DoorFlags is:

class DoorFlags final : public enums::Flags<DoorFlags, DoorFlag, uint16_t>
{
public:
    using Flags::Flags;

public:
#define X_DEFINE_ACCESSORS(UPPER_CASE, lower_case, CamelCase, friendly) \
    bool is##CamelCase() const { return contains(DoorFlag::UPPER_CASE); }
    X_FOREACH_DOOR_FLAG(X_DEFINE_ACCESSORS)
#undef X_DEFINE_ACCESSORS

public:
    // REVISIT: this name is different from the rest */
    inline bool needsKey() const { return isNeedKey(); }
};

inline constexpr const DoorFlags operator|(DoorFlag lhs, DoorFlag rhs) noexcept
{
    return DoorFlags{lhs} | DoorFlags{rhs};
}

Comment 7 Fedora Release Engineering 2019-04-26 18:53:28 UTC
There has been at least one successfull build after mass rebuild.

mmapper-2.8.0-1.fc30: https://koji.fedoraproject.org/koji/buildinfo?buildID=1245232


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