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

[Documentation] MacOS 10.15 beginner: docu not correct #14446

Closed
rowild opened this issue Jun 13, 2021 · 9 comments · Fixed by emscripten-core/emsdk#843
Closed

[Documentation] MacOS 10.15 beginner: docu not correct #14446

rowild opened this issue Jun 13, 2021 · 9 comments · Fixed by emscripten-core/emsdk#843

Comments

@rowild
Copy link

rowild commented Jun 13, 2021

Hi, dear emscripten guys!

I wanted to post my observations when installing emscripten on macOS Catalina, for which the explanations in the documentation are not correct (this very likely also concerns other macOS versions (and maybe even Linux?)). This might have to do with a version change that is not yet reflected in the docu (but since I am new to emscripten, I can't say).

Not sure if this is at all useful to you guys – if not, please close this issue. Thank you!

Reminder: With Catalina, zsh is the standard shell (not bash anymore).

My observation relate to mainly this page:
https://emscripten.org/docs/building_from_source/verify_emscripten_environment.html

To check emscripten installation, simply use
emcc --check
(not ./emcc --check)

To run a test, navigate to
cd upstream/emscripten/tests/
(not cd emscripten/<version of emscripten you installed>)

and run
emcc hello_world.cpp
(not ./emcc tests/hello_world.cpp)

Important: While it is essential to remove ./ when using emcc, it is not essential with other commands (like emsdk, which works both ways).

UPDATE
A follow-up question regarding zsh and environment variables:

Does emscripten actually support zsh? The reason I ask is that, as soon as I add source ...emsdk/emsdk_env.sh"' >> $HOME/.zshrc (NOT bash-profile), i keep getting this message:
Setting environment variables: PATH=[...]
The message stems from emsdk.py (line 2727), which checks all kinds of shells, but not for zsh, and fires this message in the context of an error log. This is strange, because I actually did set the env vars and the folders via dot-files like this:

# emscripten.config (included in .zshrc via `source emscripten.config`)

# append to path the ZSH way
path+=/Volumes/_III_/Z_WWW/emsdk
path+=/Volumes/_III_/Z_WWW/emsdk/upstream/emscripten
path+=/Volumes/_III_/Z_WWW/emsdk/node/14.15.5_64bit/bin

export EMSDK=/Volumes/_III_/Z_WWW/emsdk
export EM_CONFIG=/Volumes/_III_/Z_WWW/emsdk/.emscripten
export EMSDK_NODE=/Volumes/_III_/Z_WWW/emsdk/node/14.15.5_64bit/bin/node
export EMSDK_PYTHON=/Volumes/_III_/Z_WWW/emsdk/python/3.9.2-1_64bit/bin/python3

source /Volumes/_III_/Z_WWW/emsdk/emsdk_env.sh

Why do I get an error?

@sbc100
Copy link
Collaborator

sbc100 commented Jun 14, 2021

The "./" in the command line "./emcc --check" is needed when you are checking out emscripten from source and not necessarily adding to the path. I think this is the same for zsh and bash. Those instructions are for folks who are not using emsdk, but have emscripten checked out from git. I do think we could make it more clear perhaps? Perhaps if we instruct folks to add emscripten to their PATH first when we can skip the "./"? But I personally don't add emscripten to my PATH so there are at least some developers who won't want that. Alternatively we could change those commands to <emscripten_root>/emcc .. so they can work for any emscripten location?

@sbc100
Copy link
Collaborator

sbc100 commented Jun 15, 2021

Setting environment variables is not an error as such is just informing you of what its doing.

If you don't do anything else if you use emsdk_env.sh. The following lines are basically duplicating what emsdk_env.sh is doing for you.

path+=/Volumes/_III_/Z_WWW/emsdk
path+=/Volumes/_III_/Z_WWW/emsdk/upstream/emscripten
path+=/Volumes/_III_/Z_WWW/emsdk/node/14.15.5_64bit/bin

export EMSDK=/Volumes/_III_/Z_WWW/emsdk
export EM_CONFIG=/Volumes/_III_/Z_WWW/emsdk/.emscripten
export EMSDK_NODE=/Volumes/_III_/Z_WWW/emsdk/node/14.15.5_64bit/bin/node
export EMSDK_PYTHON=/Volumes/_III_/Z_WWW/emsdk/python/3.9.2-1_64bit/bin/python3

You should either use emsdk_env.sh or do this manual config yourself, but not both. Bear in mind if you do it manually rather then using emsdk_env.sh then your stuff could break if emsdk layout changes in the future.

@rowild
Copy link
Author

rowild commented Jun 15, 2021

Thank you for your feedback, @sbc100 !

Does this mean i should NOT include the source /Volumes/_III_/_Z... line to get rid of the terminal message? There is so much more in that file that I thought I need it anyway.

The message is shown every time a terminal window is started, which is disturbing. I assume that when I let the emscripten shell script do all the setup, that message will still appear each and every time, maybe even more verbose. Is there a reason why emscripten prints that message to the console?

As for the use of './': The thing is that is fails when, as you say, the path is set. So it should be mentioned somehow, maybe a simple line would do: "Mac users (and Linux?): Keep in mind that './' is not needed when you add emsdk to your path variables."

@sbc100
Copy link
Collaborator

sbc100 commented Jun 15, 2021

The ./ prefix works as long as you are in the emscripten directory, and fails when you are now, regardless of the PATH content. I agree we should make that more clear somehow. I did recently remove a bunch of the ./ usage from the docs in #14073.. but maybe we could do more.

@sbc100
Copy link
Collaborator

sbc100 commented Jun 15, 2021

The emsdk_env.sh will output message to stderr whenever you run it. Perhaps there is some way it can be run globally, just once, rather than on every new terminal. My memory of how .profile and .bashrc works in this respect is not serving me well but I think its possible. We could also add some kind of --quiet option to emsdk so that when run from a login script it can optionally skip those messages.

@sbc100
Copy link
Collaborator

sbc100 commented Jun 15, 2021

It looks like using ~/.zprofile might be the answer you are looking for to avoid seeing those messages in every new terminal.

@rowild
Copy link
Author

rowild commented Jun 15, 2021

I need to remove the prefix everywhere as the screenshot shows. But I do not use .zprofile, but dot files instead, that I seem to import in the wrong place (.zshrc). I will research and test that and report back.

Bildschirmfoto 2021-06-15 um 09 19 42

@sbc100
Copy link
Collaborator

sbc100 commented Jun 15, 2021

I believe the .zprofile is the name of the zsh equivalent of .bash_profile just like .zshrc is the equivalent of .bashrc.

I also believe that this is the reason we recommend using .bash_profile over .bashrc.. so that you don't see those messages each time you start a shell.

@rowild
Copy link
Author

rowild commented Jun 17, 2021

I moved source /Volumes/_III_/Z_WWW/emsdk/emsdk_env.sh (and ONLY that line, none other that I previously had) first to .zenv (which is the place where best to put paths according to many resources on StackOverflow and zsh) and later to .zprofile. But none of these options suppressed that console messages, which are huge (see screenshot again, please).

I will deactivate emscripten, whenever I do not need it, but I would still like to ask you kindly to document a proper way how to keep emscripten quiet in zsh / oh-m-zsh. - Thank you!

Bildschirmfoto 2021-06-17 um 08 21 04

sbc100 added a commit to emscripten-core/emsdk that referenced this issue Jun 17, 2021
lewing added a commit to dotnet/emsdk that referenced this issue Jan 28, 2022
* Improve emscripten-releases-tags.txt to support mutliple aliases (#837)

Also, improve reporting of version resolution. e.g.:

```
$ ./emsdk  install sdk-latest
Resolving SDK alias 'latest' to '2.0.23'
Resolving SDK version '2.0.23' to 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit'
Installing SDK 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit'..
...
```

* bugfix: allow to install SDK binaries alone (#834)

* 2.0.24 (#839)

* Error out on attempt to activate a missing tools (#838)

Previously if a tool (any part of an SDK) was not installed
we would issue a warning and continue to active without returning
non-zero.

This meant doing `emsdk install 2.0.0 && emsdk activate latest`
would appear to be work aside from the warning messages about
latest not being installed.

This is especially annoying since we dropped support for side
by side SDK installations.  The following sequence is no longer
valid and we want to make that clear by erroring out:

```
$ emsdk install 2.0.1
$ emsdk install 2.0.2
$ emsdk activate 2.0.1
```

Since 2.0.2 replaces 2.0.1 on the filesystem the active here
could fail hard rather than just warning.

* Consistent error messages (#840)

* Point zsh and csh users to the correct startup script (#843)

Fixes: emscripten-core/emscripten#14446

* Print sys.argv when link_wrapper.py is invoked incorrectly (#847)

This should help debug cases when the link_wrapper is not invoked correctly.

* Support linking with `-o filename` (#849)

When linking with `-o filename` (such as in various CMake build checks), the parameter passed to the linker is a temporary file, and it is passed as a bare filename (i.e. relative path without a `'/'`). In such cases, `outdir` would have been the empty string, and the final `tar` command would fail (actually the call to `subprocess.check_call(…)` is what fails).

* 2.0.25 (#850)

* 2.0.26 (#858)

* 2.0.26-lto (#861)

* 2.0.27 (#868)

Includes LTO and non-LTO, with non-LTO as the default

* 2.0.28 (#871)

* Use `.json` extension for emscripten-releases-tags.json. NFC (#870)

* Add LTO build for 2.0.28 (#873)

* Small fix for Bazel instructions. (#875)

In the past the instructions were to copy `emscripten_toolchain` into the project dir, now it downloads emsdk as a package so the `bazelrc` part has to refer to `@emsdk`.

* Version 2.0.29 (#878)

* 2.0.29-lto (#881)

* Fix release name for 2.0.29-lto (#885)

Fixes #884

* [Bazel] fix llvm bin path (#888)

* Add arm64 fastcomp releases to emsdk_manifest.json (#891)

This was missing from emsdk_manifest.json and should alow older fastcomp
SDKs to be install on M1 apple hardware (in emulation mode).

Fixes: #889

* 2.0.30 (#893)

* Fix error handling: untargz() in emsdk.py (#895)

Make untargz() in emsdk.py return False if tar command failed.

* Fix passing -DLLVM_ENABLE_PROJECTS directive to CMake - it does not want to see double quotes in the field passed to it. (#898)

* Fix emscripten-version parsing (#902)

See emscripten-core/emscripten#15144

* 2.0.31 (#906)

* bazel: pass -g instead of -g4 for wasm_asan feature (#904)

* Add embind example to Bazel docs (#910)

* Add embind example to Bazel docs

* address feedback

* Run buildifier on bazel/ (#913)

* Update build_bazel_rules_nodejs to fix closure compiles (#912)

* Update build_bazel_rules_nodejs to fix closure compiles

* Fix spacing in update_bazel_workspace.sh script

* space

* 2.0.32 (#915)

* Improve flags in bazel example (#917)

* Add back node.js 12.18.1 packages for Windows 7 support. (#877)

* Update CMAKE_OSX_DEPLOYMENT_TARGET from 10.11 to 10.14 (#924)

Apparently 10.11 is no longer good enough to run the latest version of
binaryen.  Specifically since binaryen switched to using std::variant it
now fails to build with this set to 10.11.

This is also the version used on the emscripten-releases CI which builds
the emsdk binaries:
https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/src/build.py#673

* Revert "Update CMAKE_OSX_DEPLOYMENT_TARGET from 10.11 to 10.14 (#924)"

This reverts commit 99e5e02.

* 2.0.33 (#922)

I add to temporarily disable the test_binaryen_from_source test
under macOS to work around:
WebAssembly/binaryen#4299

* 2.0.34 (#925)

* Bump EmscriptenVersion to 2.0.34

* Fix bad edit

Co-authored-by: Sam Clegg <sbc@chromium.org>
Co-authored-by: Yulong Wang <yulong.fs@gmail.com>
Co-authored-by: Attila Oláh <attilaolah@gmail.com>
Co-authored-by: Attila Oláh <atl@google.com>
Co-authored-by: Derek Schuff <dschuff@chromium.org>
Co-authored-by: Danny B <danila.bespalov@gmail.com>
Co-authored-by: Brad Kotsopoulos <bkotsopoulos@snapchat.com>
Co-authored-by: Matt Gucci <matt9ucci@gmail.com>
Co-authored-by: juj <jujjyl@gmail.com>
Co-authored-by: walkingeyerobot <mitch@thefoley.net>
Co-authored-by: Kevin Lubick <kjlubick@users.noreply.github.com>
Co-authored-by: Larry Ewing <lewing@microsoft.com>
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 a pull request may close this issue.

2 participants