jazz2-native icon indicating copy to clipboard operation
jazz2-native copied to clipboard

Error compiling on Fedora 40

Open musuruan opened this issue 1 year ago • 16 comments

Jazz² Resurrection version

2.7.0

System information

Fedora 40

Issue description

When compiling on F40 with Fedora optflags I get the following error:

/builddir/build/BUILD/jazz2-native-2.7.0/Sources/simdjson/simdjson.cpp: In function ‘simdjson::fallback::(anonymous namespace)::stage2::tape_builder::parse_document<false>(simdjson::fallback::dom_parser_implementation&, simdjson::dom::document&)simdjson::error_code’:
/builddir/build/BUILD/jazz2-native-2.7.0/Sources/simdjson/simdjson.cpp:16640:49: error: inlining failed in call to ‘always_inline’ ‘simdjson::fallback::(anonymous namespace)::stage2::json_iterator::walk_document<false, simdjson::fallback::(anonymous namespace)::stage2::tape_builder>(simdjson::fallback::(anonymous namespace)::stage2::tape_builder&)simdjson::error_code’: target specific option mismatch
16640 | simdjson_warn_unused simdjson_inline error_code json_iterator::walk_document(V &visitor) noexcept {
      |                                                 ^~~~~~~~~~~~~
/builddir/build/BUILD/jazz2-native-2.7.0/Sources/simdjson/simdjson.cpp:17077:39: note: called from here
17077 |   return iter.walk_document<STREAMING>(builder);
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/builddir/build/BUILD/jazz2-native-2.7.0/Sources/simdjson/simdjson.cpp:16640:49: error: inlining failed in call to ‘always_inline’ ‘simdjson::fallback::(anonymous namespace)::stage2::json_iterator::walk_document<false, simdjson::fallback::(anonymous namespace)::stage2::tape_builder>(simdjson::fallback::(anonymous namespace)::stage2::tape_builder&)simdjson::error_code’: target specific option mismatch
16640 | simdjson_warn_unused simdjson_inline error_code json_iterator::walk_document(V &visitor) noexcept {
      |                                                 ^~~~~~~~~~~~~
/builddir/build/BUILD/jazz2-native-2.7.0/Sources/simdjson/simdjson.cpp:17077:39: note: called from here
17077 |   return iter.walk_document<STREAMING>(builder);
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
gmake[2]: *** [CMakeFiles/jazz2.dir/build.make:1367: CMakeFiles/jazz2.dir/Sources/simdjson/simdjson.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
/builddir/build/BUILD/jazz2-native-2.7.0/Sources/Jazz2/ContentResolver.cpp: In member function ‘Jazz2::ContentResolver::RequestMetadata(Death::Containers::BasicStringView<char const>)’:
/builddir/build/BUILD/jazz2-native-2.7.0/Sources/Jazz2/ContentResolver.cpp:571:48: warning: ‘count’ may be used uninitialized [-Wmaybe-uninitialized]
  571 |                                         } else if (count > 1) {
      |                                                ^~
/builddir/build/BUILD/jazz2-native-2.7.0/Sources/Jazz2/ContentResolver.cpp:486:40: note: ‘count’ was declared here
  486 |                                 size_t count;
      |                                        ^~~~~
gmake[2]: Leaving directory '/builddir/build/BUILD/jazz2-native-2.7.0/redhat-linux-build'
gmake[1]: Leaving directory '/builddir/build/BUILD/jazz2-native-2.7.0/redhat-linux-build'
gmake[1]: *** [CMakeFiles/Makefile2:103: CMakeFiles/jazz2.dir/all] Error 2
gmake: *** [Makefile:159: all] Error 2

optflags are:

$ rpm --eval %optflags
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer

It is probably gcc14 related.

Steps to reproduce

I am compiling the SDL version.

Build log: build.log

musuruan avatar Jun 27 '24 17:06 musuruan

The error is in simdjson which is 3rd party library (in combination with GCC), so I'm not sure how I would fix it. Disabling inline for entire simdjson (behind some CMake parameter) is probably all I can do for you. Or you can report it to simdjson repo to get some feedback from them. It works fine in my standard Fedora 40.

deathkiller avatar Jun 28 '24 11:06 deathkiller

I see that simdjson is already packaged for a lot of distributions: https://repology.org/project/simdjson/versions

Would it be feasible to use the library version instead of bundling it?

musuruan avatar Jun 28 '24 15:06 musuruan

I would rather keep it as is and fix the cause properly than add an option to link to the system library (which would only be used by you). It would only increase the complexity of the build system.

deathkiller avatar Jun 28 '24 16:06 deathkiller

I cannot reproduce the issue. Reposted from https://github.com/simdjson/simdjson/issues/2217

$ more /etc/redhat-release
Fedora release 40 (Forty)
$ uname -a
Linux fedora-40 5.14.0-362.13.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Dec 13 14:07:45 UTC 2023 x86_64 GNU/Linux
$ g++ --version
g++ (GCC) 14.1.1 20240701 (Red Hat 14.1.1-7)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ quickstart.cpp simdjson.cpp  -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
$ ./a.out
100 results.

quickstart.cpp:

#include <iostream>
#include "simdjson.h"
using namespace simdjson;
int main(void) {
    ondemand::parser parser;
    padded_string json = padded_string::load("twitter.json");
    ondemand::document tweets = parser.iterate(json);
    std::cout << uint64_t(tweets["search_metadata"]["count"]) << " results." << std::endl;
}

Note that simdjson is part of systems such as Node.js which are widely distributed over many, many systems.

lemire avatar Jul 17 '24 20:07 lemire

It is probably gcc14 related.

The simdjson version that is part of jazz2-native is 3.9.4 which does support GCC 14. Definitively.

However, you do not appear to be using the current code. Look at the error message which points at line 16640. Here is what you have at line 16640 in the simdjson.cpp file part of jazz2-native: Screenshot 2024-07-17 at 4 10 55 PM

lemire avatar Jul 17 '24 20:07 lemire

The report should not affect versions after PR https://github.com/deathkiller/jazz2-native/pull/64

lemire avatar Jul 17 '24 20:07 lemire

Thanks for trying to reproduce it!

I think I was using some newer version of simdjson from master, not sure which one. Now it's updated to the latest release 3.9.5 if it makes any difference. But I don't know what could be wrong then.

deathkiller avatar Jul 17 '24 22:07 deathkiller

@deathkiller The version you had is fine. The updated version is also fine.

I recommend you close this issue.

The problem is that @musuruan is not using your current code.

You have nothing to fix. You either need a new release, or @musuruan needs to use GCC 13 or @musuruan can patch your release.

GCC 14 introduced some breaking changes and it broke the build of a few libraries, which in turn broke a few other systems. That was fine because no stable Linux distributed immediately adopted GCC 14 (which was first publicly released in May 2024). As far as simdjson is concerned, we fixed the issue in March (Version 3.9.1) prior to the first public release of GCC 14 (which was 14.1.)

Fedora is the bleeding-edge/experimental distribution, upstream of stable distributions like RedHat, and it went with GCC 14. Which is fine.

lemire avatar Jul 17 '24 23:07 lemire

I am using the latest jazz2 tagged release, which is 2.7.0. gcc 13 is no longer available in F40. @deathkiller can you please tag a new release which fix this issue?

musuruan avatar Jul 18 '24 16:07 musuruan

can you please tag a new release which fix this issue?

Unfortunately I can't. There is work in progress that I can't release as a new version right now, it would cause confusion. Why you can't just download the latest master branch?

deathkiller avatar Jul 18 '24 16:07 deathkiller

I was making an RPM package. Usually you package a stable version. I'll just wait for the next release.

musuruan avatar Jul 18 '24 18:07 musuruan

@musuruan Somewhat related... Fedora 40 has simdjson 3.7 as a package. It should not be able to build with GCC 14. Maybe this needs to be updated?

lemire avatar Jul 18 '24 20:07 lemire

@lemire simdjson was build for F40 (and F41) with no issue last February: https://koji.fedoraproject.org/koji/buildinfo?buildID=2410276 https://koji.fedoraproject.org/koji/buildinfo?buildID=2410264

musuruan avatar Jul 19 '24 10:07 musuruan

@musuruan I suspect that they do not build the single-header version, otherwise it would not build. Users may still encounter issue when building their own code, depending on their compile flags. We are definitively not recommending simdjson 3.7 under GCC 14. It is likely asking for trouble.

lemire avatar Jul 19 '24 12:07 lemire

@lemire yes, they don't use the single header version: https://src.fedoraproject.org/rpms/simdjson/blob/rawhide/f/simdjson.spec

I opened a bug report and ask the current maintainer to update to the latest version: https://bugzilla.redhat.com/show_bug.cgi?id=2298849

Feel free to add anything relevant I might have missed.

musuruan avatar Jul 19 '24 12:07 musuruan

Feel free to add anything relevant I might have missed.

Thanks for doing that.

We definitively want 3.9.1 or better in Fedora 40.

lemire avatar Jul 19 '24 14:07 lemire

Version 2.8.0 is out.

deathkiller avatar Aug 04 '24 10:08 deathkiller