Open MastaG opened 1 month ago
We already have variables for these, so they should be used directly, i.e. RANLIB=${KOS_RANLIB} AR=${KOS_AR}
instead of RANLIB=${KOS_CC_PREFIX}-gcc-ranlib AR=${KOS_CC_PREFIX}-gcc-ar
.
That being said, do we know why the wrong linker is being used in the first place? I haven't done a deep dive on this but rebuilding everything in kos-ports I see at least opus is also complaining too.
Because these two packages seem to use the default ar
and ranlib
from the binutils package, which do not support linking with lto enabled.
That's why we tell it to use the gcc ones instead.
Thanks for the updated variables, I've updated the commits.
@darcagn I didn't have opus failing with lto enabled, but I'm building the toolchain using gcc 14. Would it be possible to post the error?
After these two packages, the only one that doesn't build would be libjimtcl. That one doesn't build regardless of lto being used.
When the KOS toolchain has been setup to build with flto expat will fail to link with the default ar and ranlib. So we'll use the gcc ones instead.