Skip to content

lime1 #527

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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

lime1 #527

wants to merge 3 commits into from

Conversation

yamt
Copy link
Contributor

@yamt yamt commented Apr 28, 2025

cf. #525

@sbc100
Copy link
Member

sbc100 commented Apr 28, 2025

Should we have the wasi target default to lime1 instead?

@yamt
Copy link
Contributor Author

yamt commented May 2, 2025

Should we have the wasi target default to lime1 instead?

it's a valid solution. my feeling is it's app developers' choice which set of features it targets to though.

the intention of this PR is "do not enable extra features we ourselves (eg. libc) doesn't benefit from".

@sbc100
Copy link
Member

sbc100 commented May 2, 2025

Should we have the wasi target default to lime1 instead?

it's a valid solution. my feeling is it's app developers' choice which set of features it targets to though.

Up to a point this is true, but we also what sensible defaults. Developers who want to target specs older than out defaults can/should be asked to rebuild libc themselves, right?

My understanding was the lime1 was specifically designed as a sensible subset of generic that project like wasi-libc could use.

the intention of this PR is "do not enable extra features we ourselves (eg. libc) doesn't benefit from".

extended-const does benefit shared library builds (it allows data segments to express their offset without extra startup code).

@yamt
Copy link
Contributor Author

yamt commented May 6, 2025

Should we have the wasi target default to lime1 instead?

it's a valid solution. my feeling is it's app developers' choice which set of features it targets to though.

Up to a point this is true, but we also what sensible defaults. Developers who want to target specs older than out defaults can/should be asked to rebuild libc themselves, right?

My understanding was the lime1 was specifically designed as a sensible subset of generic that project like wasi-libc could use.

honestly speaking, i don't understand why "generic" and wasi should have different defaults.
is "generic" meant for web?

the intention of this PR is "do not enable extra features we ourselves (eg. libc) doesn't benefit from".

extended-const does benefit shared library builds (it allows data segments to express their offset without extra startup code).

it's true.
i'm not sure if extended-const is ubiquitous among non-web runtimes though.

@sunfishcode
Copy link
Member

Could you comment on the practical impact of this change? Which features in the wasi-libc build are you looking to disable? Or is there some other purpose here?

@yamt
Copy link
Contributor Author

yamt commented May 7, 2025

Could you comment on the practical impact of this change? Which features in the wasi-libc build are you looking to disable? Or is there some other purpose here?

reference-types makes some environment unhappy.
eg. bytecodealliance/wasm-micro-runtime#3977

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants