LTO builds fail on Linux #6575
Assignees
Labels
blocker
Blocks a release or needs immediate attention
bug
Something isn't working
core/build-fix
Follow-up fix, not released yet
Milestone
Comments
lazyfrosch
added
bug
|
It doesn't happen in local test builds with a newer Boost, not sure if the Boost version matters... |
lazyfrosch
changed the title
|
From what I can see with gdb on CentOS 7 - icinga2/lib/cli/daemonutility.cpp Lines 148 to 150 in e4e2842 |
|
I could not reproduce this on Ubuntu Xenial with boost 1.58 nor with Debian Stretch and boost 1.62. Since all fail with the same reason, it may have to do with the docker environment or docker itself 😕 |
|
I re-tested this without Docker - all on e4e2842
|
|
|
|
My bad on the tests yesterday, I guess i was too tired to notice the difference of the error 😞 Will continue to investigate what's different with the package builds! |
|
So, looks like this involved the LTO build flag or some other linker flags. Tested on CentOS 7: LTO builds are enabled for RPM and Debian builds by default |
|
Confirmed in Travis here: https://travis-ci.org/Icinga/icinga2/builds/422221143 |
lazyfrosch
changed the title
|
Unfortunately doesn't happen on macOS with clang and boost 1.67. I'll boot my CentOS dev VM. |
|
bt full on ubuntu 16.04 master: |
|
Compiling on Fedora 28 now with physical hardware (8 cpus, 16gb ram). The assert is correct about not returning any value here, neither ApplicationType nor NodeName exist in this scope. I believe that this is an ordering problem where LTO puts the StaticInitialize() methods away for some reason and they are never called. |
|
A good read: https://isocpp.org/wiki/faq/ctors#static-init-order loosely related though, but definitely a problem with the static initializers we keep using. |
|
lto on f28 seems to be broken with gcc 8.1.1, the builds crash a lot with internal errors and take quite some time. Not sure if it is a good thing to generally enable this compile time option. |
|
For some reason, moving those code parts into icinga-app don't solve the underlying problem though, as in a later step the config compiler cannot find the script variables. StaticInitialize() definitely is called, still those Namespace registrations happen from various sides. No idea so far what's going on with LTO here, need a fresh look tomorrow. Poke @gunnarbeutner ;) |
|
I'm now working on an Ubuntu box granted by @Crunsher with more resources. Interestingly enough, the Since I've read a lot about the Loader and DeferredInitializers yesterday evening, I now know that the macro Registration: Execution of static initializers: So, where's the code which creates the System namespace? Right, another Actually with the same priority (50) as the one for the IcingaApplication. It seems that the optimizations involved with LTO actually create byte code which invokes the IcingaApplication setters first, and later override them in the ScriptFrame initializer. That is why the System namespace doesn't hold the ApplicationType/Version constants, but globals for example has Changing the initialize once priority for the scriptframe initializer solves the problem with LTO builds. I have a patch nearly ready. |
dnsmichi
pushed a commit
that referenced
this issue
Sep 4, 2018
dnsmichi
pushed a commit
that referenced
this issue
Sep 4, 2018
|
Triggered a snapshot build run: https://build.icinga.com/view/Icinga%202/job/icinga2-snapshot/job/rpm-centos-7-2test/210/console |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Basically all tests fail right now on e4e2842, build worked fine as far as I see it.
https://build.icinga.com/view/Icinga%202/job/icinga2-snapshot/job/rpm-centos-6-2test/arch=x86_64/215/console
Your Environment
icinga2 --version): e4e2842The text was updated successfully, but these errors were encountered: