Release both statically linked without wasm and dynamically linked with wasm #3893
Conversation
|
How do I register my company as a WASM user? =) |
|
@wleese Point taken, I'll talk with others on the team on our options here. Do you know if kpt binaries with WASM support that is dynamically linked to glibc is useful for you? |
|
For exactly the reasons stated in the issue, we have found ourselves switching between alpine and debian. I believe we‘re now on debian, so dynamically linked would be fine |
mortent
force-pushed
the
NoCGOForRelease
branch
from
340c130
to
fd48e68
Compare
| } | ||
|
|
||
| func (f *WasmtimeFn) Run(r io.Reader, w io.Writer) error { | ||
| return fmt.Errorf("wasmtime support is not compiled into binary (check cgo settings)") | ||
| return fmt.Errorf("wasmtime support is not compiled into binary (build kpt from source for wasm support)") |
There was a problem hiding this comment.
should these error messages be changed with your most recent push? Maybe something along the lines of please download the kpt binary with wasm support instead ?
There was a problem hiding this comment.
Yeah, I've updated the language.
There was a problem hiding this comment.
I still see the old error message ‘build kpt from source for wasm support’ and your last force push didn’t appear to have any changes, did you intend to commit something?
There was a problem hiding this comment.
Yeah, I thought I had committed the change, but just noticed it wasn't included in my commit. It is updated now.
mortent
force-pushed
the
NoCGOForRelease
branch
from
fd48e68
to
7d10648
Compare
mortent
changed the title
mortent
force-pushed
the
NoCGOForRelease
branch
from
7d10648
to
eb70300
Compare
Fully functional statically linked binaries with WASM support doesn't seem to be possible, so for now we should just remove WASM support in the regular kpt releases. If there is sufficient demand, we can create dynamically linked binaries of kpt with WASM support for the most common Unix variants.
More details in #3892 (comment)
Fixes: #3892