https://github.com/wasmerio/wasmer/blob/master/lib/wasi/src/syscalls/mod.rs#L1745

                let write_permission = adjusted_rights & __WASI_RIGHT_FD_WRITE != 0;

Notably this is using the write permission, not the open flag to determine if a file is opened with write capabilities or not. This is likely intentional. The intent here seems to have been that our own VirtualFS will manage read/write access via our own fds. This is fine, but we don't check if we can open a file with write permissions, we just assume that we can. The fix should be relatively simple: we should succeed if the open flag does not have write permissions and open without write permissions. If the open flags have write enabled, then we should fail indicating a lack of underlying write permission on the FS.

Additionally, we can revisit the extent to which we manage our own permissions in regards to fd read/write in the new context of the WASI FS not trying to provide a fully platform agnostic abstraction.

FYI: I just wanted to add that for my upgrade from 10.15.6 -> 10.15.7 (I'm avoiding Big Sur :-)) I had exactly the same problem which was solved as above with the

sudo yabai --install-sa

Yes, I did a clean build.

I'm actually not surprised, because IHMO, the settings from Makefile override the otherwise provided settings.

You can try the Makefile build on your own:

make --directory=<repo-dir> build-capi 
make --directory=<repo-dir> package-capi 

After the two build steps, simply check with objdump if SONAME is present: objdump -p <repo-dir>/package/lib/libwasmer.so | grep SONAME

Thanks, Martin

Did you try to ˋcargo clean` before rebuilding the library? I'm surprised it doesn't work.

Hi @Hywan,

Thanks for your fast response. I tried out your suggested change, but unfortunately it does not work when building wasmer with Makefile in the root directory of the repository.

To adjust the Makefile, change the capi-setup section to these lines:

capi-setup:
ifeq ($(IS_WINDOWS), 1)
  RUSTFLAGS += -C target-feature=+crt-static
else
ifeq ($(IS_LINUX), 1)
  RUSTFLAGS += -C link-arg=-Wl,-soname,libwasmer.so
endif
endif

Maybe you should consider using my original change in the build.rs file, because this would affect all build types and hence eliminate the need to modify two places.

Thanks, Martin

What happened?

Accented characters are replaced by other characters

What did you expect to happen?

Accented characters are correctly reproduced

Steps to reproduce

1. In a win10 DOS command prompt run "emacs -nw"
2. Open any file that contains accented characters

Note: a) When running simply "emacs" there is no problem (but I need the terminal version to work). b) In config.el, when I set the doom theme to a theme that doesn't exist, I will get a warning on startup "theme not found", however the characters are represented correctly. However the evil layer doesn't work. c) in gitbash SDK-64, when I run "winpty emacs -nw" the characters are displayed correctly. Gitbash has several environment variables / paths set differently. d) I tried several doom themes, to no avail

System Information

• Emacs version: 28.0.50 native compiled
• Emacs distro: Doom Emacs
• Operating system: Windows 10
• Installed commit of doom-themes: latest
• Which theme are you using: doom-one

We need to investigate to see if it's worth it :-). Thank you for the proposal!

@Hywan could you please consider using cargo-c? I can send you a patch if you need help in converting the c-api build system (it is mainly removing the build.rs since cargo-c does already everything for you :)).

See #2430 for the bug fix. Can you please help us to see if it fixes your issue? Thanks!

Please @MartinKolbAtWork, can you try this patch and see if it works in your context?

Description

See https://github.com/wasmerio/wasmer/issues/2429 for more context.

The idea is to use our .cargo/config.toml file to set the SONAME correctly to libwasmer.so only on Linux.

Fix #2429.

Review

• [ ] Add a short description of the change to the CHANGELOG.md file

The shared library libwasmer.so does not have an SONAME specified. This can be checked using this command: objdump -p libwasmer.so | grep SONAME

When libwasmer.so is consumed in CMake, the linker produces a wrong output file due to the missing SONAME. There is a workaround for this in CMake, but according to a reply from the CMake folks, the missing SONAME is a bug that must be fixed by the library provider: https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562 “The libwasmer.so file should have a SONAME. If it doesn't, that's a bug in the wasmer package”

The problem is inherent for all Rust builds of cdylibs: https://github.com/rust-lang/cargo/issues/5045 The Rust community did not fix this since 2018 (see issue above), but fortunately it’s easy to fix for library creators. You just need to put the following code into the build.rs of the library:

if cfg!(target_os = "linux") {
    println!("cargo:rustc-cdylib-link-arg=-Wl,-soname,libwasmer.so");
}

I tried putting these lines into lib/c-api/build.rs, and then libwasmer.so was built correctly, including a SONAME entry.

Could you please fix this issue?

Thanks Martin

Summary

As a normal case in building from source on Linux/Unix. I will use

make 
sudo make install

to build and install from source code.

But follow these steps, there will be an error like this by default:

target/release/wasmer config --pkg-config | install -Dm644 /dev/stdin "/usr/local"/lib/pkgconfig/wasmer.pc
unset WASMER_DIR # Make sure WASMER_INSTALL_PREFIX is set during build
error: failed to retrieve the wasmer config
│   1: failed to retrieve the WASMER_DIR environment variables
╰─> 2: environment variable not found

Then, I need to find the document, and the document is not clear about this, https://github.com/wasmerio/wasmer/blob/master/PACKAGING.md. Actually, we need to add WASMER_INSTALL_PREFIX in the make stage, not make install stage.

By default, makefile use DISTDIR as the target directory. https://github.com/wasmerio/wasmer/blob/144300e0bc51d01290680a46cd30a6ca76ed0359/Makefile#L632

I saw the WASMER_INSTALL_PREFIX is introduced by this commit: https://github.com/wasmerio/wasmer/commit/80ec06ffab9d7af017a5a5490d153a2230f9374a

I don't get the point for this variable, and I think it makes some confusion.

If we want to configure the path, we need to add two environment variables, WASMER_INSTALL_PREFIX to recompile the whole project.

Add a short description of the change to the CHANGELOG.md file: Seems like an irrelevant fix - Necessary?

Not needed in this case I believe.

<!-- Prior to submitting a PR, review the CONTRIBUTING.md document for recommendations on how to test: https://github.com/wasmerio/wasmer/blob/master/CONTRIBUTING.md#pull-requests

-->

Description

Fixes #2413, also improves PACKAGING.md

Alternatively, I could make it so make install errors out with a nice and clean error message if that variable is not set (and tells people that they're not supposed to make install themselves?), or default WASMER_INSTALL_PREFIX to /usr/local (at the danger of being missed, resulting in incorrect installs).

Review

• [ ] Add a short description of the change to the CHANGELOG.md file: Seems like an irrelevant fix - Necessary?

I don't get the point for this variable, and I think it makes some confusion.

I might have wanted to document that more. (In my defence, you're picking an undocumented installation route, I think.)

The intention behind having DESTDIR and WASMER_INSTALL_PREFIX is that many distros stage installation in some /tmp/foo/bar/usr path before building a package, and then install that to /usr. Problem is: When wasmer is being make installed to DESTDIR=/tmp/foo/bar/usr, how would it know that it's supposed to include its headers from /usr/include? So, WASMER_INSTALL_PREFIX must be compiled in.

If we want to configure the path, we need to add two environment variables, WASMER_INSTALL_PREFIX to recompile the whole project.

I'm not sure what you mean by this. Is this a change that needs to be contributed to wasmer's source, or something that a user needs to do to install/use wasmer?

Then, I need to find the document, and the document is not clear about this, https://github.com/wasmerio/wasmer/blob/master/PACKAGING.md.

That's the distro packaging manual, and unrelated to your case. Can I somehow make that clearer? (You're not packaging for a distro, are you?)

I would say that maybe 50% of our crates can be used in no_std. I don't know how much work would be required to me it up to 100%. Anyone would like to help on that front? I can coordinate the project.

You might want to mention that the xft use flag must be enabled for app-editors/emacs in order for the fonts to render correctly.

See #4876

@savageCW

In order for the fonts to render correctly on Gentoo you need to enable the xft use-flag for app-editors/emacs.

This can be done like so...

# echo "app-editors/emacs xft" >> /etc/portage/package.use/emacs

Holding down mouse mod key disable focus follow temporary

yabai -m config mouse_modifier               ctrl

<!--

YOUR PR WILL NOT BE ACCEPTED IF IT DOES NOT MEET THE FOLLOWING CRITERIA:

• [x] It targets the develop branch
• [ ] I've searched for similar pull requests and found nothing
• [ ] This change is NOT in Doom's do-not-PR list: https://doomemacs.org/d/do-not-pr (GRR, this requires Discourse also???)
• [ ] If I've bumped any packages, I've done so according to https://doomemacs.org/d/how2bump
• [x] I've linked any relevant issues and PRs below
• [x] All my commit messages are descriptive and distinct

-->

This changes the FAQ link to a link that works for all users.

Is there a reason this currently points to Discourse which (seems to) force one to have a login to even see the content?

I tried to check the "do-not-PR" list but it has the same issue - of evidently being locked behind needing a Discourse account?

Any updates? This would be really fantastic for embedded platforms and kernels. Wasmer seems one of the most complete wasm engines.

Just to be clear since there are two issues in this thread, the HostFile::poll issue is still open on 2.0.0.

@iyefrat - on the "bibtex-actions improvements?" todo issue about menus.

We actually have a WIP progress PR to add embark-act at-point functionality, which includes as well a keymap specific to that.

Ideally, I'd like to get these "simple menus" with descriptoins working in which-key and, by extension, Doom.

https://github.com/bdarcus/bibtex-actions/pull/57/commits/33a9617194b31dbfd036513a7cf05b6b8c2a534e

But I never had any success, and it seems it has to wait on an unmerged, and stagnant, which-key PR.

If necessary, I can just provide the Doom-specific mapping, so we get nice and consistent menus with embark-act both at-point and in-buffer.

Description

On macOS, echo always enables interpretation of backslach sequences (like \n). On Linux, the -e flag must be used. Even if this -e flag is absent from the macOS man's page for echo(1), it is accepted and ignored, thus we can safely use it in our Makefile.

To test this patch:

$ # before
$ make package-wapm
$ cat package/bin/wax
#!/bin/bash\nwapm execute "$@"
$
$ # after
$ make package-wapm
$ cat package/bin/wax
#!/bin/bash
wapm execute "$@"

This patch fixes #2425.

Review

• [x] Add a short description of the change to the CHANGELOG.md file