Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build fails on Fedora 40 #282

Open
es-fabricemarie opened this issue May 7, 2024 · 2 comments · May be fixed by #286
Open

build fails on Fedora 40 #282

es-fabricemarie opened this issue May 7, 2024 · 2 comments · May be fixed by #286

Comments

@es-fabricemarie
Copy link

Hi,
When building on Fedora40, I'm getting this error:

g++ -Wall -Wextra -Werror -O3 -I../include -D_FILE_OFFSET_BITS=64 -std=c++11 -Wold-style-cast -Wno-missing-field-initializers -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -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  -L../lib -Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes  -o ../bin/bees bees.o bees-context.o bees-hash.o bees-resolve.o bees-roots.o bees-thread.o bees-trace.o bees-types.o bees-version.o bees-usage.o ../lib/libcrucible.a -lcrucible -lpthread
In member function ‘__ct ’,
    inlined from ‘__ct ’ at bees-trace.cc:53:2,
    inlined from ‘operator()’ at bees-roots.cc:764:4,
    inlined from ‘__invoke_impl’ at /usr/include/c++/14/bits/invoke.h:61:36,
    inlined from ‘__invoke_r’ at /usr/include/c++/14/bits/invoke.h:150:33,
    inlined from ‘_M_invoke’ at /usr/include/c++/14/bits/std_function.h:290:30:
/usr/include/c++/14/bits/std_function.h:391:17: error: ‘<anonymous>’ may be used uninitialized [-Werror=maybe-uninitialized]
  391 |             __x._M_manager(_M_functor, __x._M_functor, __clone_functor);
      |                 ^
/usr/include/c++/14/bits/std_function.h: In function ‘_M_invoke’:
/usr/include/c++/14/bits/std_function.h:267:7: note: by argument 2 of type ‘const union _Any_data & {ref-all}’ to ‘_M_manager’ declared here
  267 |       _M_manager(_Any_data& __dest, const _Any_data& __source,
      |       ^
bees-roots.cc:764:25: note: ‘<anonymous>’ declared here
  764 |                         BEESTRACE("calling transid_max_nocache");
      |                         ^
lto1: all warnings being treated as errors
make[2]: *** [/tmp/cc47wSlM.mk:23: /tmp/cc8Lchk2.ltrans7.ltrans.o] Error 1
make[2]: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:43: ../bin/bees] Error 1
make[1]: Leaving directory '/home/builduser/rpmbuild/BUILD/bees/src'
make: *** [Makefile:39: src] Error 2

Looks like the default configuration on Fedora40 compiler is pretty strict.
I could remove the -Werror=maybe-uninitialized flag of course, but it defeats the purpose.

Hope this helps.

@KyleGospo KyleGospo linked a pull request Jul 23, 2024 that will close this issue
@Zygo
Copy link
Owner

Zygo commented Jan 19, 2025

That looks more like a library or toolchain issue. If it's real, we probably don't want to run the resulting binary. If it's not real, it's up to the toolchain maintainers to fix.

BEESTRACE is used everywhere in bees, and it would be disastrous if it's reading uninitialized data.

@Zygo
Copy link
Owner

Zygo commented Jan 21, 2025

I tried reproducing this on a freshly updated 40...

[root@localhost bees]# cat /etc/fedora-release 
Fedora release 40 (Forty)
[root@localhost bees]# g++ --version
g++ (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)

The g++ is newer than this issue. Does it still happen? Is there anything required to reproduce except make -j10?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants