configure: error: Link Time Optimisation is not supported ... Building on FreeBSD

[datafatmunger]

I'm trying to get a successful build on FreeBSD but I'm met with:

checking if Link Time Optimisation works with AR=ar... no
checking if Link Time Optimisation works with AR=gcc-ar... no
configure: error: Link Time Optimisation is not supported (see config.log for details).
gmake[1]: *** [Makefile:5086: configure-mpfr] Error 1

[waddlesplash]

We don't explicitly enable LTO in the build-cross-tools script, so it must have just decided to use it anyway.

I think anevilyak still builds on FreeBSD, perhaps he can comment here?

[anevilyak]

I ran into this as well, but couldn't for the life of me figure out why it was deciding to require that, so it remains as yet unresolved over here. Admittedly though, I'm more or less clueless about gcc's build system in general, so I'm really not sure where to look.

[waddlesplash]

Perhaps GCC can't be compiled with Clang and/or Clang's binutils anymore (or maybe it never could, and now that Clang is the default compiler on FreeBSD, this is an issue?)

[anevilyak]

At least in my case, this was using gcc from FreeBSD's ports tree as a starting point, since the last time I tried, Clang failed even earlier.

[datafatmunger]

Hum ... well I can't seem to do a Haiku based build because I have interrupt issues: https://dev.haiku-os.org/ticket/14579#comment:11 and the system locks up during the build (actually debugging that issue is why I'm trying to build Haiku in the first place).

I'm only trying FreeBSD because that's apparently where a lot of the drivers have be ported from ...

Does someone have a recommendation on a Linux distribution which is building Haiku successfully?

[korli]

Replying to datafatmunger:

Does someone have a recommendation on a Linux distribution which is building Haiku successfully?

For instance: Ubuntu x86_64 for the x86_64 build.

[tqh]

The FreeBSD ports gcc or its related utils arn't compiled with link time optimization flags, which one or more of the gcc dependencies I updated requires and checks for. IMO they should fix that..

I use Ubuntu for building, you can build both 32 bit and 64 bit builds on both 32 bit and 64 bit linux installations.

[korli]

You didn't include a full log... but it seems to be a failure of the mpfr configure script. One alternative is to install mpfr, gmp, and mpc from ports. And eventually add --with-mpfr=/usr/gnu64/lib, --with-gmp=/usr/gnu64/lib, --with-mpc=/usr/gnu64/lib at ​https://git.haiku-os.org/haiku/tree/build/scripts/build_cross_tools_gcc4#n280 to indicate non-standard locations.

[tqh]

That is quite painful, as there are non-trivial inter-dependencies if built outside gcc. Better recompile ports gcc with link time flags.

[waddlesplash]

I'm only trying FreeBSD because that's apparently where a lot of the drivers have be ported from ...

Only the network drivers. And I don't know why you would try to build there "because of the drivers"; we don't use FreeBSD headers, tools, or anything like that in the build process that are not also already in the tree.

Does someone have a recommendation on a Linux distribution which is building Haiku successfully?

Yes, just about any one of them works. I use Ubuntu, I know of others who use CentOS, Arch, SUSE, Manjaro, etc.

At least in my case, this was using gcc from FreeBSD's ports tree as a starting point, since the last time I tried, Clang failed even earlier.

Perhaps try adding --no-link-time-optimization (I think that's the flag name?) to the configure invocation for binutils in build/scripts/build_cross_tools_gcc4 script and trying again.

[datafatmunger]

Replying to waddlesplash:

Only the network drivers. And I don't know why you would try to build there "because of the drivers"; we don't use FreeBSD headers, tools, or anything like that in the build process that are not also already in the tree.

lol, only because it's what i have installed at the moment thanks your comment on this thread/ticket: https://dev.haiku-os.org/ticket/14579 ...

In any case probably doesn't matter because the original issue I'm trying to troubleshoot is probably unrelated to the network driver at all ... and I'm guess is a kernel interrupt issue, as it manifests in more than just network disruption.

[waddlesplash]

Yes, based on your comments in that ticket and the syslog messages, it sounds like the USB bus driver might be eating interrupts that aren't its own. The OHCI driver has been known to be buggy...

[waddlesplash]

Fixed in btrev43139.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone