Learn Emcc →Environment Variable Error→ llvm
The Emscripten Compiler Frontend (emcc)
emcc ⇒ Your C/C++ code can access files using the normal libc stdio API (fopen, fclose, etc.) using-files
macでは./emcc -v じゃなくて ./つけないで emcc -v でexecute
LLVM intermediate representation ("LLVM IR")
C言語LLVM逆コンパイル面白い C言語が動くためにどう実装しているかわかる。こわくないLLVM入門
-o Output
original言語つくれるんじゃないかとllvm触ってると思う。
h → header file
emscripten使わないでRustのwasm-pack使う未来もあり
独自のclangとnodeが提供されるので、通常の開発で使っているバージョンと衝突する可能性 devtool/.emscripten のnodeとpythonのところがめっちゃ怪しいというか、ここしか盲点はない。
Error治ったからemscriptenのtutorialやりたい
ls -l コマンドで確認したとき、 -> と表示されていればシンボリックリンクです。
-Sは assembly outputなのか
exec $SHELL -l
emscriptenとwabtをlocalに移動させたからシンボリックリンクつくりたい
ローカルなインストールは /usr/local/ 一般的なローカルでのインストール（ソースからコンパイル、バイナリをダウンロードなど）においては、 /usr/local/ にインストールすればよい。 /usr/local/ 以下の配置方法としては、 • /usr/local// ディレクトリを作成して配置
◦ Golang のデフォルトインストールがこのレイアウト（ /usr/local/go/ ）
◦ PATH の通し方については、シンボリックリンクを /usr/local/bin に配置
◦ ソースは /usr/local/src/<app> に配置
とする。
ln -s /usr/local/bin/g++-12 /usr/local/bin/g++
WebAssemblyは、Webブラウザ上で高速に動作するバイナリコードの仕様を指す言葉です。WebAssemblyの頭文字を取って、「Wasm」と略されることもあります。ネイティブに近いパフォーマンスをWebブラウザで発揮できるため、Webブラウザを介したアプリケーションに適したフォーマットとして評価されています。 なお、WebAssemblyはJavaやPHPなどのプログラミング言語ではありません。WebブラウザでコンパイルされたC/C++やRustを実行する仕組み（アセンブラ）を指すものです。Webアプリケーションが複雑になるとともに、JavaScriptでは処理速度が追い付かないことを補完する目的で誕生しました
C++などで書かれたコードをコンパイルし、WebAssemblyバイトコード（WASMコード）に変換することで、Webブラウザ上での実行が可能になるという仕組みです。>
The locker seems pretty safe.
Wrap the locker password with cvctf{} and submit it.
https://safe-locker-1-cb82cf79e839.surge.sh
Note: This is an easy challenge. Do not overthink it!
Emscriptenをdownload
┌─(~/devtool/emsdk)─────────────┐
└─(14:24:15 on main)──> ./emsdk install latest 127 ↵ ──(Sat,May13)─┘
Resolving SDK alias 'latest' to '3.1.38'
Resolving SDK version '3.1.38' to 'sdk-releases-03ecb526947f6a3702a0d083083799fe410d3893-64bit'
Installing SDK 'sdk-releases-03ecb526947f6a3702a0d083083799fe410d3893-64bit'..
Installing tool 'node-15.14.0-64bit'..
Downloading: /Users/$HOME/devtool/emsdk/zips/node-v15.14.0-darwin-x64.tar.gz from https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/node-v15.14.0-darwin-x64.tar.gz, 30516053 Bytes
Unpacking '/Users/$HOME/devtool/emsdk/zips/node-v15.14.0-darwin-x64.tar.gz' to '/Users/$HOME/devtool/emsdk/node/15.14.0_64bit'
Done installing tool 'node-15.14.0-64bit'.
Installing tool 'python-3.9.2-64bit'..
Downloading: /Users/$HOME/devtool/emsdk/zips/python-3.9.2-3-macos-x86_64.tar.gz from https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/python-3.9.2-3-macos-x86_64.tar.gz, 31899321 Bytes
Unpacking '/Users/$HOME/devtool/emsdk/zips/python-3.9.2-3-macos-x86_64.tar.gz' to '/Users/$HOME/devtool/emsdk/python/3.9.2_64bit'
Done installing tool 'python-3.9.2-64bit'.
Installing tool 'releases-03ecb526947f6a3702a0d083083799fe410d3893-64bit'..
Downloading: /Users/$HOME/devtool/emsdk/zips/03ecb526947f6a3702a0d083083799fe410d3893-wasm-binaries.tbz2 from https://storage.googleapis.com/webassembly/emscripten-releases-builds/mac/03ecb526947f6a3702a0d083083799fe410d3893/wasm-binaries.tbz2, 344206357 Bytes
Unpacking '/Users/$HOME/devtool/emsdk/zips/03ecb526947f6a3702a0d083083799fe410d3893-wasm-binaries.tbz2' to '/Users/$HOME/devtool/emsdk/upstream'
Done installing tool 'releases-03ecb526947f6a3702a0d083083799fe410d3893-64bit'.
Done installing SDK 'sdk-releases-03ecb526947f6a3702a0d083083799fe410d3893-64bit'.
┌─(~/devtool/emsdk)─────────────┐
└─(17:18:15 on main)──> ./emsdk activate latest ──(Sat,May13)─┘
Resolving SDK alias 'latest' to '3.1.38'
Resolving SDK version '3.1.38' to 'sdk-releases-03ecb526947f6a3702a0d083083799fe410d3893-64bit'
Setting the following tools as active:
node-15.14.0-64bit
python-3.9.2-64bit
releases-03ecb526947f6a3702a0d083083799fe410d3893-64bit
Next steps:
- To conveniently access emsdk tools from the command line,
consider adding the following directories to your PATH:
/Users/$HOME/devtool/emsdk
/Users$HOME/devtool/emsdk/upstream/emscripten
- This can be done for the current shell by running:
source "/Users/$HOME/devtool/emsdk/emsdk_env.sh"
- Configure emsdk in your shell startup scripts by running:
echo 'source "/Users/$HOME/devtool/emsdk/emsdk_env.sh"' >> $HOME/.zprofile
┌─(~/devtool/emsdk)─────────────┐
└─(17:22:59 on main)──> source ./emsdk_env.sh ──(Sat,May13)─┘
Setting up EMSDK environment (suppress these messages with EMSDK_QUIET=1)
Adding directories to PATH:
PATH += /Users/$HOME/devtool/emsdk/upstream/emscripten
```python
┌─(~/devtool/emsdk)─────────────┐
└─(17:23:51 on main)──> emcc -v ──(Sat,May13)─┘
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.38 (9eff02bc816c50ab0e3b70a3bd5b72a8dc2893a2)
clang version 17.0.0 (https://github.com/llvm/llvm-project 004bf170c6cbaa049601bcf92f86a9459aec2dc2)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /Users/$HOME/devtool/emsdk/upstream/bin
pathをzshrcに書いて source ~/.zshrc した後 mainでもどこでも動くようになった
┌─(~)───────────────────────────┐
└─(17:34:22 on main ✖ ✹ ✭)──> emcc -v ──(Sat,May13)─┘
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.38 (9eff02bc816c50ab0e3b70a3bd5b72a8dc2893a2)
clang version 17.0.0 (https://github.com/llvm/llvm-project 004bf170c6cbaa049601bcf92f86a9459aec2dc2)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /Users/$HOME/devtool/emsdk/upstream/bin
emcc base64.c xxtea.c passCheck.c -o passCheck.js -s EXPORTED_FUNCTIONS="['_checker']" -s EXPORTED_RUNTIME_METHODS=ccall,cwrap -s EXPORT_ES6=1 -s MODULARIZE=1 -s ALLOW_MEMORY_GROWTH=1
//details
This command compiles several C source files (base64.c, xxtea.c, and passCheck.c) into a JavaScript module named "passCheck.js". The resulting module can be used in a JavaScript environment (e.g. a web browser or Node.js) to execute the C code from those source files.
The "-s EXPORTED_FUNCTIONS" option specifies the C functions that will be exposed as callable functions in the JavaScript environment. In this case, the "checker" function will be exposed and available to be called from JavaScript code.
The "-s EXPORTED_RUNTIME_METHODS" option specifies the runtime methods that will be exported and made available to JavaScript code. The "ccall" and "cwrap" runtime methods are included, which allow JavaScript code to call C functions that have been exposed using "-s EXPORTED_FUNCTIONS".
The "-s EXPORT_ES6" option specifies that the resulting module will use ECMAScript 6 (ES6) syntax, which is a newer version of the JavaScript language. This can enable the use of newer JavaScript features and syntax.
The "-s MODULARIZE" option specifies that the resulting module will be written in a modular format that can be imported and used in other JavaScript modules.
The "-s ALLOW_MEMORY_GROWTH" option allows the module's memory to grow dynamically during runtime, which can be useful for applications that require dynamic memory allocation.
Error(まだ未解決）⇒ まず解決するのにemcc のコマンドの理解が出来ていないのが問題。なにが -o されるのか。
XXTEA(Corrected Block TEA (often referred to as XXTEA) is a block cipher designed to correct weaknesses in the original Block TEA. ⇒ XTEA (eXtended TEA) is a block cipher designed to correct weaknesses in TEA.
emcc base64.c xxtea.c passCheck.c -o passCheck.js -s EXPORTED_FUNCTIONS="['_checker']" -s EXPORTED_RUNTIME_METHODS=ccall,cwrap -s EXPORT_ES6=1 -s MODULARIZE=1 -s ALLOW_MEMORY_GROWTH=1
このoutに使っているc fileの理解も必要。
┌─(..._safe_locker/solution)────┐
└─(18:19:25 on main ✖ ✹ ✭)──> emcc base64.c xxtea.c passCheck.c -o passCheck.js -s EXPORTED_FUNCTIONS="['_checker']" -s EXPORTED_RUNTIME_METHODS=ccall,cwrap -s EXPORT_ES6=1 -s MODULARIZE=1 -s ALLOW_MEMORY_GROWTH=1
In file included from base64.c:1:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/string.h:61:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:913:2: error: Unsupported architecture
#error Unsupported architecture
error architecture not supported on mac os
The reason is that my computer's environment variable is incorrect.
ref: EmscriptenでC言語実装のHelloWorldを動かしてみた
※ ~/.emscripten にEmscripten用のLLVM/clang、Node.jsのパスが記録されているので、 PATHに追加しなくてもプログラムをビルドできます。
//~/.emscripten
import os
emsdk_path = os.path.dirname(os.getenv('EM_CONFIG')).replace('\\', '/')
NODE_JS = emsdk_path + '/node/15.14.0_64bit/bin/node'
PYTHON = emsdk_path + '/python/3.9.2_64bit/bin/python3'
LLVM_ROOT = emsdk_path + '/upstream/bin'
BINARYEN_ROOT = emsdk_path + '/upstream'
EMSCRIPTEN_ROOT = emsdk_path + '/upstream/emscripten'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]
Targetの変更関係あるかな？
To change the target on Emscripten from wasm32 to x86-x84, you need to specify the appropriate target flag during the compilation process. Follow these steps:
- Open a terminal or command prompt.
- Navigate to the directory where your source code is located.
- Set the target flag when invoking the Emscripten compiler (
emcc), as follows:
emcc source.c -o output.html -s WASM=0
Here, source.c is the name of your source code file, output.html is the desired name for the output file, and the -s WASM=0 flag disables WebAssembly compilation.
- Run the
emcccommand to compile your code with the new target. Emscripten will generate x86-84 compatible code instead of WebAssembly.
After the compilation process completes, you will have an output file (output.html) that contains the compiled x86-84 code. Keep in mind that running the generated code may require a suitable x86-84 environment or emulator to execute properly.
emcc 初期設定やtargetの変更についてもっと詳しく調べる。
Verifying the Emscripten Development Environment
- Sanity testはclear
linker→https://en.wikipedia.org/wiki/Linker_(computing)
└─(23:02:38 on main ✖ ✹ ✭)──> emcc --check ──(Tue,M
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.37-git
shared:INFO: (Emscripten: Running sanity checks)
- Build a basic exampleの段階で相変わらずerror吐いてしまう
┌─(...n/3.1.37/libexec/test)────┐
└─(08:03:19)──> emcc hello_world.cpp ──(Wed,May17)─┘
In file included from hello_world.cpp:6:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:913:2: error: Unsupported architecture
#error Unsupported architecture
brew doctor したけど関係あるかなぁ もともとVScodeで機能していなかったstdc++.h消した
└─(16:42:52 on main)──> brew doctor ──(Wed,May17)─┘
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/bits/stdc++.h
Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause formulae that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
mono
node
python@3.11
Warning: You have uncommitted modifications to Homebrew/homebrew-core.
If this is a surprise to you, then you should stash these modifications.
Stashing returns Homebrew to a pristine state but can be undone
should you later need to do so for some reason.
cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core && git stash -u && git clean -d -f
Uncommitted files:
?? Formula/binutils-.rb
Warning: Some installed formulae are missing dependencies.
You should `brew install` the missing dependencies:
brew install python@3.10
Run `brew missing` for more details.
- Emscriptenは（ブラウザ想定なら）既存のプログラムがほとんどそのまま動く...けれどサイズが大きい
vs
- 「素」のwasmだけなのでコンピューティング以外（IOなど）は何もできないけれど小さい
- 必要ならwasm-bindgenを組み合わせて
独自のclangとnodeが提供されるので、通常の開発で使っているバージョンと衝突する可能性
devtool/.emscripten のnodeとpythonのところがめっちゃ怪しいというか、ここしか盲点はない。
//初期設定の.emscripten
import os
emsdk_path = os.path.dirname(os.getenv('EM_CONFIG')).replace('\\', '/')
NODE_JS = emsdk_path + '/node/15.14.0_64bit/bin/node'
PYTHON = emsdk_path + '/python/3.9.2_64bit/bin/python3'
LLVM_ROOT = emsdk_path + '/upstream/bin'
BINARYEN_ROOT = emsdk_path + '/upstream'
EMSCRIPTEN_ROOT = emsdk_path + '/upstream/emscripten'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]
.emscripten設定を変えてみた source ./emsdk_env.sh でしっかり反映させる
//まずnodeとpythonだけ変更
import os
emsdk_path = os.path.dirname(os.getenv('EM_CONFIG')).replace('\\', '/')
NODE_JS = '/Users/$HOME/.volta/bin/node'
PYTHON = '/usr/local/bin/python3'
LLVM_ROOT = emsdk_path + '/upstream/bin'
BINARYEN_ROOT = emsdk_path + '/upstream'
EMSCRIPTEN_ROOT = emsdk_path + '/upstream/emscripten'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]
└─(22:27:55 on main)──> source ./emsdk_env.sh 127 ↵ ──(Wed,May17)─┘
Setting up EMSDK environment (suppress these messages with EMSDK_QUIET=1)
Setting environment variables:
Clearing existing environment variable: EMSDK_NODE
Clearing existing environment variable: EMSDK_PYTHON
emsdk_path のrootも変えた
import os
emsdk_path = '/Users/$HOME/devtool/emsdk/'
NODE_JS = '/Users/$HOME/.volta/bin/node'
PYTHON = '/usr/local/bin/python3'
LLVM_ROOT = emsdk_path + '/upstream/bin'
BINARYEN_ROOT = emsdk_path + '/upstream'
EMSCRIPTEN_ROOT = emsdk_path + '/upstream/emscripten'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]
- あと確認するのはGCCとclangの関係性くらいか ref:MacでGCCを"正しく"環境構築しよう！
Golangの設定でCGO使うためにLLVM無効にした記憶があるんだよな。それがErrorの原因かも
The cgo tool is enabled by default for native builds on systems where it is expected to work. It is disabled by default when cross-compiling as well as when the CC environment variable is unset and the default C compiler (typically gcc or clang) cannot be found on the system PATH.
You can override the default by setting the CGO_ENABLED environment variable when running the go tool: set it to 1 to enable the use of cgo, and to 0 to disable it. The go tool will set the build constraint "cgo" if cgo is enabled. The special import "C" implies the "cgo" build constraint, as though the file also said "//go:build cgo". Therefore, if cgo is disabled, files that import "C" will not be built by the go tool. (For more about build constraints see https://golang.org/pkg/go/build/#hdr-Build_Constraints).
- CPATHが当時github issueを参照にしただけだから設定が怪しい
- CGO_ENABLED=1; → 0に変更することでdisable (terminalから設定したい)
- llvmはlinkさせてもいいんじゃないかとも思うがemscriptenとconflictするかな？
go runでハマったときの修正点の確認
llvmをunlinkしてみる
[runtime/cgo: fails to build after updating to Mojave](https://github.com/golang/go/issues/27921)
brew unlink llvm
Unlinking /usr/local/Cellar/llvm/12.0.0_1... 0 symlinks removed.
/.zshrc
この辺の初期のPATH周りも怪しい
export PATH="/usr/local/opt/llvm/bin:$PATH"
export PATH="/usr/local/opt/python@3.11/bin:$PATH"
# for golang project go run CPATH追加（GCC/G++がコンパイル中に.hファイルを探すための環境変数）
# already unlink llvm@12 before via this pass
export CPATH="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
export CGO_ENABLED=1; export CC=gcc;
CGO_ENABLED=0: Enables statically linked binaries to make the application more portable. It allows you to use the binary with source images that don't support shared libraries when building your container image.
How to enable CGO? The cgo tool is enabled by default for native builds on systems where it is expected to work. It is disabled by default when cross-compiling. You can control this by setting the CGO_ENABLED environment variable when running the go tool: set it to 1 to enable the use of cgo, and to 0 to disable it.
-
つまりCGOを0(無効化)しておけばいいんじゃないのか emscripten使いたい場合は。CC=gccではなく,clang/llvmにすればemscriptenが使えるのではないか。
-
CPATHがXcode依存ってなんかやだなぁと。(clangってこと)
-
brewでGCC管理したくないなぁ…
-
brewのllvmはunlink状態でemsdkのupstreamバイナリの中にあるのを動かしている状態 （Emscripten用のLLVM/clang)
現段階ではC++ファイルのコンパイルに用いられる
g++コマンドを打つと、GCC環境のコンパイラではなくClang環境のコンパイラが呼び出されます。下記では、コマンドの呼び出し先を変えることで、g++コマンドを打つことでGCC環境のコンパイラが呼び出されるようにします。
インストールされたGCCの確認
インストール時に
/usr/local/binからインストールされたGCC環境のコンパイラへとシンボリックリンクが張られます。このシンボリックリンクは下記のコマンドによって確認することができます。出力は自分の環境のものです。
- 結局emsdkのclangをemscriptenでは使っているのでこのgcc達もあとでしっかり環境構築しよう。
┌─(~)───────────────────────────┐
└─(03:04:30 on main ✖ ✹ ✭)──> ls -l /usr/local/bin | grep g++ ──(Thu,May18)─┘
lrwxr-xr-x 1 $HOME admin 31 7 May 19:33 g++-13 -> ../Cellar/gcc/13.1.0/bin/g++-13
lrwxr-xr-x 1 $HOME admin 46 14 May 19:18 wasm32-clang++ -> ../Cellar/emscripten/3.1.37/bin/wasm32-clang++
lrwxr-xr-x 1 $HOME admin 51 14 May 19:18 wasm32-wasi-clag++ -> ../Cellar/emscripten/3.1.37/bin/wasm32-wasi-clang++
lrwxr-xr-x 1 $HOME admin 53 7 May 19:33 x86_64-apple-darwin21-g++-13 -> ../Cellar/gcc/13.1.0/bin/x86_64-apple-darwin21-g++-13
実行可能なg++コマンド
まず、呼び出されるg++コマンドは下記のwhichコマンドで確認することができます。また、-aオプションを用いると、実行可能な任意のg++コマンドを確認することができます。ここまでの手順に従っていれば、いずれも同じ出力になるはずです。
└─(03:06:02 on main ✖ ✹ ✭)──> which g++ ──(Thu,May18)─┘
/usr/bin/g++
└─(03:09:18 on main ✖ ✹ ✭)──> which -a g++ ──(Thu,May18)─┘
/usr/bin/g++
/usr/bin/g++
GCC環境とClang環境
さらに、/usr/local/bin/g++はインストールしたGCC環境のC++コンパイラを指し、/usr/bin/g++はすでにインストールされているClang環境のC++コンパイラ5を指します。また、それぞれのコンパイラの情報については下記のコマンドで確認することができます。出力は自分の環境のものです。
- GCC環境のC++コンパイラ。。。nothing!! 【改善済み】
┌─(~)───────────────────────────┐
└─(03:10:10 on main ✖ ✹ ✭)──> /usr/local/bin/g++ -v ──(Thu,May18)─┘
zsh: no such file or directory: /usr/local/bin/g++
- Clang環境のC++コンパイラ
└─(03:18:03 on main ✖ ✹ ✭)──> /usr/bin/g++ -v 127 ↵ ──(Thu,May18)─┘
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
ついにError解決
golangのCPATH設定をzshrcから消した！ついにemscripten testが通った うおおおおお
┌─(...tream/emscripten/test)────┐
└─(04:15:18 on main ✭)──> emcc hello_world.c ──(Thu,May18)─┘
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libGL.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libGL.a" for subsequent builds)
system_libs:INFO: compiled 3 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libal.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libal.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libhtml5.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libhtml5.a" for subsequent builds)
system_libs:INFO: compiled 2 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libstubs-debug.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libstubs-debug.a" for subsequent builds)
system_libs:INFO: compiled 2 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libnoexit.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libnoexit.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc-debug.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libc-debug.a" for subsequent builds)
system_libs:INFO: compiled 1020 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libdlmalloc.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libdlmalloc.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libcompiler_rt.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a" for subsequent builds)
system_libs:INFO: compiled 175 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc++-noexcept.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libc++-noexcept.a" for subsequent builds)
system_libs:INFO: compiled 48 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc++abi-debug-noexcept.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libc++abi-debug-noexcept.a" for subsequent builds)
system_libs:INFO: compiled 16 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libsockets.a... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/sysroot/lib/wasm32-emscripten/libsockets.a" for subsequent builds)
system_libs:INFO: compiled 21 inputs
cache:INFO: - ok
そしてついに本題のsolutionへ
emccでjsとwasm fileを作る。
passCheck.c is compiled by Emscripten to passCheck.js and passCheck.wasm. Online implementation of base64 and xxtea in C are also used.
┌─(..._safe_locker/solution)────┐
└─(04:45:27 on main ✖ ✹ ✭)──> ls ──(Thu,May18)─┘
base64.c index.html style.css xxtea.h
base64.h passCheck.c xxtea.c
┌─(..._safe_locker/solution)────┐
└─(04:45:28 on main ✖ ✹ ✭)──> emcc base64.c xxtea.c passCheck.c -o passCheck.js -s EXPORTED_FUNCTIONS="['_checker']" -s EXPORTED_RUNTIME_METHODS=ccall,cwrap -s EXPORT_ES6=1 -s MODULARIZE=1 -s ALLOW_MEMORY_GROWTH=1
cache:INFO: generating system asset: symbol_lists/3f30c330be03729a20b079d7d47334d97e3c61d5.json... (this will be cached in "/usr/local/Cellar/emscripten/3.1.37/libexec/cache/symbol_lists/3f30c330be03729a20b079d7d47334d97e3c61d5.json" for subsequent builds)
cache:INFO: - ok
ついにemccコマンド使いこなせた…嬉しすぎる
jsとwasmが誕生。
┌─(..._safe_locker/solution)────┐
└─(04:52:34 on main ✖ ✹ ✭)──> ls ──(Thu,May18
base64.c index.html passCheck.js style.css xxtea.h
base64.h passCheck.c passCheck.wasm xxtea.c
このタイミングで.emscriptenをもとに戻すとどうなるか検証
結果 defaultの.emscriptenでぜんぜん動く。Errorの原因は完全に.zhsrcのCPATHの設定だった。
┌─(...tream/emscripten/test)────┐
└─(05:20:16 on main ✭)──> emcc hello_world.c ──(Thu,May18)─┘
shared:INFO: old sanity: 3.1.38|/Users/$HOME/devtool/emsdk//upstream/bin|17.0
shared:INFO: new sanity: 3.1.38|/Users/$HOME/devtool/emsdk/upstream/bin|17.0
shared:INFO: (Emscripten: config changed, clearing cache)
shared:INFO: (Emscripten: Running sanity checks)
cache:INFO: generating system headers: sysroot_install.stamp... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot_install.stamp" for subsequent builds)
cache:INFO: - ok
cache:INFO: generating system asset: symbol_lists/bf2dac56d03bb43ce3033d09fab95ffdac0a8732.json... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/symbol_lists/bf2dac56d03bb43ce3033d09fab95ffdac0a8732.json" for subsequent builds)
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libGL.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libGL.a" for subsequent builds)
system_libs:INFO: compiled 3 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libal.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libal.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libhtml5.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libhtml5.a" for subsequent builds)
system_libs:INFO: compiled 2 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libstubs-debug.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libstubs-debug.a" for subsequent builds)
system_libs:INFO: compiled 2 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libnoexit.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libnoexit.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc-debug.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libc-debug.a" for subsequent builds)
system_libs:INFO: compiled 1021 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libdlmalloc.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libdlmalloc.a" for subsequent builds)
system_libs:INFO: compiled 1 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libcompiler_rt.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a" for subsequent builds)
system_libs:INFO: compiled 175 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc++-noexcept.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-noexcept.a" for subsequent builds)
system_libs:INFO: compiled 48 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc++abi-debug-noexcept.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++abi-debug-noexcept.a" for subsequent builds)
system_libs:INFO: compiled 16 inputs
cache:INFO: - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libsockets.a... (this will be cached in "/Users/$HOME/devtool/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libsockets.a" for subsequent builds)
system_libs:INFO: compiled 21 inputs
cache:INFO: - ok
自分のPATHじゃなくてもいけるので.emscriptenはdefault設定で使っていく。またtestとtutorialを進めていく中で不具合があれば変更する。
brewでのGCC環境再構築(for atCoder)とかは置いといて、llvmはbrew unlinkのままでいいかな。またCGO環境のときにスムーズに環境構築したいから。自分のMac上のclang/llvmの環境もbestな状態にしておきたい。
ref: [mac OS 10.13(High Sierra) で gdb を使う]https://qiita.com/yuzu_afro/items/988020dd65fb4f43962a
GNU debbugerの生存確認
┌─(...tream/emscripten/test)────┐
└─(05:30:37 on main ✭)──> gdb -v ──(Thu,May18)─┘
GNU gdb (GDB) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
└─(05:31:01 on main ✭)──> where clang ──(Thu,May18)─┘
/usr/bin/clang
/usr/local/opt/llvm/bin/clang
//cellarのsimbolic link
/usr/bin/clang
└─(14:41:28 on main ✖ ✹ ✭)──> ls -l /usr/bin | grep clang ──(Thu,May18
-rwxr-xr-x 76 root wheel 167120 4 Apr 11:24 clang
-rwxr-xr-x 76 root wheel 167120 4 Apr 11:24 clang++
-rwxr-xr-x 76 root wheel 167120 4 Apr 11:24 clangd
┌─(~)──────────────────────────
clang++はC++
clangdはLLVMのフロントであるclangをベースとしたサーバーで、LLVMプロジェクトが公式に開発している
The llvm-g++ command is the LLVM C++ front end. It is a modified version of g++ that compiles C++/ObjC++ programs into native code, LLVM bitcode or assembly language, depending upon the options.
By default, llvm-g++ compiles to native objects just like GCC does. If the -emit-llvm option is given then it will generate LLVM bitcode files instead. If -S (assembly) is also given, then it will generate LLVM assembly.
usr/bin にg++が２つあるっていわれているけど確認できていない。brewのシンボリックリンクかと思ったけど、それはlocalにある。
└─(14:13:29 on main ✭)──> where g++ ──(Thu,May18)─┘
/usr/bin/g++
/usr/bin/g++
└─(14:41:08 on main ✖ ✹ ✭)──> ls -l /usr/bin | grep g++ ──(Thu,May18
-rwxr-xr-x 76 root wheel 167120 4 Apr 11:24 clang++
-rwxr-xr-x 76 root wheel 167120 4 Apr 11:24 g++
-rwxr-xr-x 76 root wheel 167120 4 Apr 11:24 llvm-g++
localにはCellarのgccとemscriptenのclangの各シンボリックリンクが入っている
┌─(~)───────────────────────────┐
└─(04:34:13 on main ✖ ✹ ✭)──> ls -l /usr/local/bin | grep g++ ──(Thu,May18)─┘
lrwxr-xr-x 1 $HOME admin 31 7 May 19:33 g++-13 -> ../Cellar/gcc/13.1.0/bin/g++-13
lrwxr-xr-x 1 $HOME admin 46 14 May 19:18 wasm32-clang++ -> ../Cellar/emscripten/3.1.37/bin/wasm32-clang++
lrwxr-xr-x 1 $HOME admin 51 14 May 19:18 wasm32-wasi-clag++ -> ../Cellar/emscripten/3.1.37/bin/wasm32-wasi-clang++
lrwxr-xr-x 1 $HOME admin 53 7 May 19:33 x86_64-apple-darwin21-g++-13 -> ../Cellar/gcc/13.1.0/bin/x86_64-apple-darwin21-g++-13
シンボリックリンク作成してemscriptenのPATH通しといた(大満足)
└─(22:31:57 on main ✭)──> ln -s /usr/local/emsdk/upstream/emscripten /usr/local/bin/emscripten
┌─(/usr/local/emsdk)────────────┐
└─(22:39:54 on main ✭)──> exec $SHELL -l ──(Thu,May18)─┘