On Fri, 2020-07-24 at 13:39 -0600, Jerry James wrote:
On Fri, Jul 24, 2020 at 1:35 PM Jeff Law <law(a)redhat.com>
wrote:
> Just a note on z3.
>
> I've been trying to track down what I think is an uninstantiated template issue
> that's exposed by LTO. I've been chasing it on/off over the last day or
two
> without success. So if you get a build failure that looks like this:
>
> /usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x110): undefined
reference to `lp::lp_solver<double, double>::get_variable_name[abi:cxx11](unsigned
int) const'
> /usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x168): undefined
reference to `lp::lp_solver<double, double>::get_variable_name[abi:cxx11](unsigned
int) const'
> /usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x1b0): undefined
reference to `lp::lp_solver<double, double>::get_variable_name[abi:cxx11](unsigned
int) const'
> collect2: error: ld returned 1 exit status
>
> Just disable LTO via the usual mechanism (%define _lto_cflags %{nil}). We'll
> revisit any opt-outs again between F33 and F34 and re-evaluate them.
Thanks for the heads-up, Jeff. I have not seen that in a mock build,
but if there hasn't been a successful Rawhide compose since the LTO
bits landed, that is no surprise. I have a vague memory of asking z3
upstream to add some explicit template instantiations around the time
gcc 10 landed in Rawhide, so there is precedent if we need to do so
again.
Whatever you committed in the last couple days seems to have fixed the
issue. I
just got a clean build of z3 on x86_64.
jeff