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

expat and libyaml: fix build with flto #76

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

MastaG
Copy link

@MastaG MastaG commented Jul 24, 2024

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.

@MastaG MastaG changed the title expat: fix build with flto expat and libyaml: fix build with flto Jul 24, 2024
@gyrovorbis gyrovorbis added the build failure Report of or fix for build issues such as compiler warnings or errors. label Aug 3, 2024
@darcagn
Copy link
Contributor

darcagn commented Aug 8, 2024

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.

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.
When the KOS toolchain has been setup to build with flto,
libyaml will fail to link with the default ar and ranlib.
So we'll use the gcc ones instead.
@MastaG
Copy link
Author

MastaG commented Aug 8, 2024

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.

@MastaG
Copy link
Author

MastaG commented Aug 8, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build failure Report of or fix for build issues such as compiler warnings or errors.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants