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.

Sign up for GitHub

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

Jump to bottom

Some quick questions for the flag of compiling C++ code #131

Closed
leonwanghui opened this issue May 13, 2020 · 4 comments
Closed

Some quick questions for the flag of compiling C++ code #131

leonwanghui opened this issue May 13, 2020 · 4 comments

Comments

@leonwanghui
Copy link

Sorry to interrupt, but I found that C++ can only support be compiled with -fno-exceptions flag, so my question is if it can also support -fno-rtti flag, and what impact it would cause if I enable this flag when compiling C++ code with clang++ compiler? Thanks!
@sunfishcode
Copy link
Member

Yes, wasi-sdk supports -fno-rtti. That flag typically reduces the code size of C++ applications, by avoiding the extra type metadata and strings.

@leonwanghui
Copy link
Author

@sunfishcode Thanks for the quick answers, if I enable -fno-rtti, would it have some impact on wasm binary file, for example reducing wasm binary file size, or removing some type metadata in wasm IR? Please correct me if I have some misunderstanding, thanks~

@sunfishcode
Copy link
Member

Yes, it typically reduces the size of wasm binaries.

@leonwanghui
Copy link
Author

Thanks!

kildom pushed a commit to kildom/clang-wasi-port that referenced this issue Jul 14, 2021
@sunfishcode
Use consistent style for wasi-libc C source files. (WebAssembly#131)
ca9046d 
For now, this means using `//`-style comments in .c source files (though
not public header files), and spaces rather than tabs. No strong opinion
here; this is just what the majority of the current code is using.

This also synchronizes basics/crt/crt1.c with libc-bottom-half's
version, though this is just a cleanup as the former isn't currently used
by the main wasi-libc build.
alexcrichton pushed a commit to alexcrichton/wasi-sdk that referenced this issue Apr 5, 2023
@sbc100
Roll wasi-libc to include snapshot1 (WebAssembly#84)
baa9b68 
This brings in the following changes:

f645f49 Update signal macros after upgrade to snapshot1 (WebAssembly#144)
8b3266d github actions: pin checkout action to v1 (WebAssembly#145)
410c660 Use constructor functions for optional init routines. (WebAssembly#142)
fe13053 c header generation updated for reorganized witx ast (WebAssembly#139)
cd74e1d Correct the version of WebAssembly#136 on master (WebAssembly#141)
446cb3f Wasi snapshot preview1 (WebAssembly#140)
54102f0 Ignore rights in libpreopen. (WebAssembly#129)
8c9e1c6 Make the `__original_main` definition weak, fixing -flto. (WebAssembly#138)
cf81683 Optimize `fmin`, `fmax`, etc. (WebAssembly#120)
deb8eae Don't pre-check capabilities in `openat`. (WebAssembly#130)
ca9046d Use consistent style for wasi-libc C source files. (WebAssembly#131)
951cc3e Fix unintended recursion in __wasilibc_register_preopened_fd. (WebAssembly#133)
5216983 Avoid a `strdup` call in `__wasilibc_populate_libpreopen`. (WebAssembly#128)
70099d4 Don't link in libpreopen initialization code when it isn't needed. (WebAssembly#127)
ec4549d Temporarily disable the use of `__heap_base`. (WebAssembly#132)
a214f1c Use __heap_base by dlmalloc (WebAssembly#114)
a94d2d0 Avoid varargs conventions when calling open (WebAssembly#126)
7fcc4f2 Revamp and simplify the libpreopen code. (WebAssembly#110)
eb7230c Remove more unsupported headers. (WebAssembly#123)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sunfishcode @leonwanghui