I just tried to compile Rust example project into webassembly using emscripten on Windows, but it causes error.
How can I fix it?
What I did:
Install emscripten
>git clone https://github.com/emscripten-core/emsdk.git
>cd emsdk
>git pull
>emsdk install latest
>emsdk activate latest
>emsdk_env.bat
Install rustup
Download rustup-init.exe from https://www.rust-lang.org/ja/tools/install
and run it
Install wasm32 target by rustup
>rustup target add wasm32-unknown-emscripten
Create example project
>cargo new --bin web_assembly
>cd web_assembly
Try to compile, but error occurs
>cargo build --target wasm32-unknown-emscripten
Compiling web_assembly v0.1.0 (F:\github\rusttest\web_assembly)
error: linking with `emcc.bat` failed: exit code: 1
|
= note: "cmd" "/c" "emcc.bat" "-s" "DISABLE_EXCEPTION_CATCHING=0" "-L" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib" "-L" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\self-contained" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.0.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.1.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.2.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.3.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.4.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.5.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.6.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.7.rcgu.o" "-o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.js" "-s" "EXPORTED_FUNCTIONS=[\"_main\",\"_rust_eh_personality\"]" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.3a2jxscq1lvbzwaf.rcgu.o" "-O0" "--memory-init-file" "0" "-g4" "-s" "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]" "-L" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps" "-L" "F:\\github\\rusttest\\web_assembly\\target\\debug\\deps" "-L" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libstd-28368703ab79076a.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libpanic_unwind-c6cbccdff18b55f7.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\librustc_demangle-a5ffc5310c14c91c.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libhashbrown-08c349e57dac68c0.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\librustc_std_workspace_alloc-ce3363c7b27912b6.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libunwind-686deac84d1c117a.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libcfg_if-1aefc0615f4a87c4.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\liblibc-35a51890c8428321.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\liballoc-d41456f5d5a426f6.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\librustc_std_workspace_core-2a7cc4e4deb2c4e8.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libcore-997b7450818c8186.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libcompiler_builtins-68f9d21fef2c27f2.rlib" "-l" "c" "-s" "ERROR_ON_UNDEFINED_SYMBOLS=1" "-s" "ASSERTIONS=1" "-s" "ABORTING_MALLOC=0" "-Wl,--fatal-warnings"
= note: shared:INFO: (Emscripten: Running sanity checks)
emcc: warning: please replace -g4 with -gsource-map [-Wdeprecated]
error: undefined symbol: __gxx_personality_v0 (referenced by top-level compiled C/C++ code)
warning: Link with `-s LLD_REPORT_UNDEFINED` to get more information on undefined symbols
warning: To disable errors for undefined symbols use `-s ERROR_ON_UNDEFINED_SYMBOLS=0`
warning: ___gxx_personality_v0 may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors
emcc: error: 'F:/github/emsdk/node/14.15.5_64bit/bin/node.exe F:\github\emsdk\upstream\emscripten\src\compiler.js C:\Users\Username\AppData\Local\Temp\tmpang8muuo.txt' failed (1)
error: aborting due to previous error
error: could not compile `web_assembly`
To learn more, run the command again with --verbose.
Versions of tools:
>emcc.bat --version
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.20-git (8ed0f4fee2abd04923c2fd2bf44835169ce2ac2e)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>rustup --version
rustup 1.24.1 (a01bd6b0d 2021-04-27)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.52.1 (9bc8c42bb 2021-05-09)`
If you want/need emscripten (to use c or c++ based crates or enjoy working dwarf debug) here is how to fix the build error.
The error cause is described here: https://github.com/rust-lang/rust/issues/85821
Workaround is to:
Create stub for the missing function (save as file gxx_personality_v0_stub.cpp):
#include "unwind.h"
#include "stdint.h"
extern "C" _Unwind_Reason_Code __gxx_personality_v0 (int version, _Unwind_Action actions, uint64_t exceptionClass, _Unwind_Exception* unwind_exception, _Unwind_Context* context) {
return _URC_NO_REASON;
}
Build using emcc:
emcc -c gxx_personality_v0_stub.cpp
Create/modify .cargo/config file:
[build]
rustflags = ["-C", "link-args=gxx_personality_v0_stub.o"]
Enjoy working latest rust (tested with v1.55.0) and emscripten (v2.0.29)
Note: Stack unwind on panic won't work with this stub. But since the function was stubbed anyway in emscripten you are not missing any functionality.
You can also use EMCC_CFLAGS as workaround:
EMCC_CFLAGS="-s ERROR_ON_UNDEFINED_SYMBOLS=0 --no-entry" cargo build --target wasm32-unknown-emscripten
In older versions this flag called EMMAKEN_CFLAGS:
EMMAKEN_CFLAGS="-s ERROR_ON_UNDEFINED_SYMBOLS=0 --no-entry" cargo build --target wasm32-unknown-emscripten
Emscripten uses tip-of-tree LLVM, which may be incompatible with the more stable version of LLVM used by Rust. That means that you have to use a particular version of Emscripten with an LLVM that closely matches Rust's version of LLVM rather than using latest.
The version of Emscripten that most closely matches Rust's LLVM since Rust 52 is Emscripten 2.0.13, so I would try using that.
The best resource documenting and tracking the best version of Emscripten to use is https://blog.therocode.net/2020/10/a-guide-to-rust-sdl2-emscripten, although it hasn't been updated for Rust 52+.
If you don't strictly require Emscripten, you should use Rust's custom WASM support, which is available through the wasm32-unknown-unknown as this is where most of Rust-related WASM development happens.
If you want an example of how to use this target, check out the Rust WASM book.
Not found the real reason of the error. Yet I identified which emcc version stopped working with rust (tested with latest stable 1.55.0). Emscripten 2.0.9 works, but Emscripten 2.0.10 fails with ___gxx_personality_v0 error.
Related
I'm trying out a new setup. I'm on a 64-bit Windows 10. I've meson example project and clang compiler stack over Visual Studio 2017. Both of those are in my PATH.
[0/1] Regenerating build files.
The Meson build system Version: 0.49.0
Source dir: C:\WORK\cpp-example\wx-example
Build dir: C:\WORK\cpp-example\wx-example\builddir
Build type: native build
Project name: wx-example
Project version: undefined
Native C++ compiler: clang++ (clang 7.0.0 "clang version 7.0.0 (tags/RELEASE_700/final)")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found wx-config '>=3.0.0' NO
Dependency WxWidgets found: NO (tried config-tool)
meson.build:8:2: ERROR: Dependency "wxwidgets" not found, tried config-tool
A full log can be found at C:\WORK\cpp-example\wx-example\builddir\meson-logs\meson-log.txt
FAILED: build.ninja
My meson.build is
project('wx-example', 'cpp')
#if build_machine.system() == 'windows'
# cpp = meson.get_compiler('cpp')
# add_project_link_arguments(['C:\WORK\wxWidgets-3.1.2\include'], language : 'cpp')
# wx_dep = cpp.find_library('wxwidgets', dirs : ['C:\WORK\wxWidgets-3.1.2\lib\vc_x64_dll'])
#else
wx_dep = dependency('wxwidgets', version : '>=3.0.0', required : true)
#endif
executable('wx-example.exe', ['main.cpp'], dependencies : [wx_dep])
Do u have any idea how to compile my example?
Maybe I should use MinGW wxWitgets package?
Meson's dependency for wxWidgets only supports wx-config tool, which was originally intended for *nix only. So you need to get wx-config Windows native port first to make it work with VC++.
BTW. Maybe even the easiest thing to do is to write it on your own, as it's just a regular console application, which parses the command line and spits to stdout the corresponding compiler/linker flags.
Maybe I should use MinGW wxWitgets package?
Well, that's, of course, possible but then you will also have to switch to gcc/g++. Moreover, Meson's wxWidgets dependency is still broken under MSYS2/MinGW. The problem is that Meson erroneously tries to execute wx-config directly, while under Windows it must be prefixed with env/sh/bash or whatever. Not a big problem to fix it, but you'll still have some work to do.
UPD.: The issue appears to be fixed in Meson 0.51.0
I'm using the nightly Rust through rustup. I'm trying to build a Windows dll for GNU Octave. Is it possible to use the libstdc++.a from Octave?
I'm able to compile, but linking fails with errors like:
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0x2c): undefined reference to `pthread_mutex_lock'
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0xa7): undefined reference to `pthread_mutex_unlock'
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0xde): undefined reference to `pthread_mutex_init'
My current hunch is that the libstdc++.a that is found isn't compatible. It is finding the one from Rust with this order of search paths:
"-L"
"C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib"
"-L" "C:\Octave\Octave-4.2.1\lib64\gcc\x86_64-w64-mingw32\4.9.4"
The gcc that ships with Octave 4.2.1 is GCC 4.9.4 released [2016-08-03]. Rust nightly has GCC 6.3 released [2016-12-21]. Do I need to do something like compile the Rust standard library with the GCC 4.9.4 from Octave? Is that possible? Full code and more details in this issue.
I installed Rust on a Windows 10 machine with rustup-init.exe - the method recommended in the Rust Book. The installer told me that Rust needs C-runtime of VS2013 or newer. I have VS2017 installed, I assumed Rust doesn't support VS2017 yet and so agreed to install C-runtime. Installation finished successfully.
main.rs:
fn main() {
println!("Hello, world!");
}
Compiling:
> rustc main.rs
error: linking with `link.exe` failed: exit code: 1
|
= note: "link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "main.0.o" "/OUT:main.exe" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-0a78323911070f99.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librand-c279a51d66700350.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcollections-d7bf31a4ca1ea637.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-d367c3ba0db49600.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-2d4bf02140c11dcb.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-add7a84d7e82d084.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-84688accbc86d6b7.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-fe2e68b21f0bdd7a.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-7fc0381594c93f56.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-ea9d77e7c23fe65c.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-91b619d34dd1f5aa.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
= note: /usr/bin/link: extra operand '/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib'
Try '/usr/bin/link --help' for more information.
error: aborting due to previous error
link.exe LIBPATH arg is specified twice.
What's going on?
> rustc --version
rustc 1.17.0 (56124baa9 2017-04-24)
As the rustup documentation says:
As mentioned on the Rust download page, there are two ABIs in use on Windows: the native (MSVC) ABI used by Visual Studio, and the GNU ABI used by the GCC toolchain. Which version of Rust you need depends largely on what C/C++ libraries you want to interoperate with: for interop with software produced by Visual Studio use the MSVC build of Rust; for interop with GNU software built using the MinGW/MSYS2 toolchain use the GNU build.
You have installed the MSVC toolchain. However, you are running the the compiler in a command shell where link.exe does not point to the MSVC linker, but instead to a GNU toolchain — MSVC does not call its linker /usr/bin/link or use options like --help!
You should configure your shell so the MSVC linker is foremost in the PATH or switch to the GNU ABI if that's your goal.
Compare the help output of the two:
$ link --help
Usage: link FILE1 FILE2
or: link OPTION
Call the link function to create a link named FILE2 to an existing FILE1.
--help display this help and exit
--version output version information and exit
GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/link>
or available locally via: info '(coreutils) link invocation'
> link /help
Microsoft (R) Incremental Linker Version 14.10.25017.0
Copyright (C) Microsoft Corporation. All rights reserved.
For help on Linker, type `link /link' or `link'
For help on Library Manager, type `link /lib' or `lib'
For help on Dumper, type `link /dump' or `dumpbin'
For help on Editor, type `link /edit' or `editbin'
For help on CvtCIL, type `link /cvtcil'
I assumed Rust doesn't support VS2017 yet
It supports VS2017 just fine; as described in the 1.17 release notes, the problem is that it cannot automatically find the MSVC installation due to changes in where MSVC installs. Running the Rust compiler from inside a shell that has the proper environment works fine.
Summary: when I try cross-compiling a .go source file that includes a C file somewhere in the file chain, targeting Windows AMD64 from a Mac host, I get:
/usr/local/go/src/runtime/cgo/gcc_windows_amd64.c:8:10: fatal error: 'windows.h' file not found
Purely Go code seems to cross compile without error; is there a way to get the proper header files for cross compilation when C files are involved?
More details: I installed LiteIDE on my Mac for working on some .go projects, and LiteIDE makes it relatively simple to target other platforms as build targets. I tested it on a small test project I had, purely Go, and it seemed to run without error.
Later I tried it on a current, larger project and had to adjust several env settings in the IDE to get it to work (complaints about C files without CGO enabled, and GOPATH not set properly even though it's set in .bash_profile and verified in echo $VARIABLE just fine.) The result is
/usr/local/go/src/runtime/cgo/gcc_windows_amd64.c:8:10: fatal error: 'windows.h' file not found
Trying to target Linux (os linux, arch amd64) gives
# runtime/cgo
ld: unknown option: --build-id=none
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've double checked I have XCode installed; gcc is installed:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr with-gxx-include- dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
...and Go is the latest version:
go version go1.6.2 darwin/amd64
I also checked that this isn't just from LiteIDE (since LiteIDE seems to override env settings and ignore what's in the terminal?); an example attempt at the console gives:
MyUsername$ env GOOS=windows GOARCH=amd64 CGO_ENABLED=1 go build -v
golang.org/x/net/html/atom
runtime/cgo
golang.org/x/crypto/ssh/terminal
golang.org/x/net/html
github.com/howeyc/gopass
# runtime/cgo
/usr/local/go/src/runtime/cgo/gcc_windows_amd64.c:8:10: fatal error: 'windows.h' file not found
github.com/andybalholm/cascadia
github.com/PuerkitoBio/goquery
I suspect this is because the application uses networking libraries in Go and I think the native libraries are still calling some C files to fill in gaps. Is there a way to get the proper libraries for building on Linux/Windows or does this need to be done on the target platforms in order to work?
Building native applications on the host platform seems to work without issue.
To enable cross-compiling for CGO you need to have a local toolchain that can compile C code for that target.
I'm not very familiar with Mac OS X, but on Arch Linux all I had to do was install mingw-w64-toolchain and compile my go code with:
env GOOS="windows" GOARCH="386" CGO_ENABLED="1" CC="i686-w64-mingw32-gcc" go build
// or to target win 64
env GOOS="windows" GOARCH="amd64" CGO_ENABLED="1" CC="x86_64-w64-mingw32-gcc" go build
On OSX, you can install mingw with homebrew: brew install mingw-w64
About the other error message though, ld: unknown option: --build-id=none seems like a bug, you might want to report that on the Go issue tracker.
I am trying to build the tests for rapidjson 0.11 (http://code.google.com/p/rapidjson/) on Mac OS X . It includes three projects: gtest (builds fine), unittest (build fails), and perftest (build fails), and when building make error out with Error 1 and Error 2.
The compiler output shows the following errors for both unittest and perftest which causes make to fail:
../../include/rapidjson/reader.h: In function ‘const char* rapidjson::SkipWhitespace_SIMD(const char*)’:
../../include/rapidjson/reader.h:116: error: ‘_SIDD_UBYTE_OPS’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_CMP_EQUAL_ANY’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_BIT_MASK’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_NEGATIVE_POLARITY’ was not declared in this scope
These pre-processor constants are related to SSE4 instructions. rapidjson can use SSE2 or SSE4.2 to speed it up, and it defaults to using SSE4.2 when building.
The makefile includes the -msse4.2 compiler switch to enable SSE4.2 support, and looking through the header files reveal that on OS X, both SSE4_1 and SSE4_2 pre-processor constants need to be defined for the SIDD... constants to be defined. For some reason, these SIDD... constants aren't being defined.
Further research showed that the -msse4 switch enables support for both SSE4.1 and SSE4.2, so I tried chaning the switch to -msse4, but it still errors out.
Not sure if the -msse4.2 switch automatically defines SSE4_2 , but I tried manually defining it, and sill no luck.
NOTE: If you want to try building it yourself on Mac, you will need to download a different premake script file, as the included one doesn't work. You can download the corrected script from the attachment on the second post here https://code.google.com/p/rapidjson/issues/detail?id=54
Any ideas on how to get it building successfully on OS X ?
Short answer - I had an older version of gcc (4.2) which didn't support -msse4.2 flag (it was introduced in gcc 4.3).
After upgrading to the latest version of gcc, the above issue disappeared:
Check which version of gcc is active with by opening a terminal and
running gcc -v
Download MacProst installer for your version of OS X from http://www.macports.org/install.php and run installer (easy way to upgrade GCC version)
Open new terminal window (must be new as PATH environment var is updated after MacPorts
install)
Check which versions of gcc you already have installed with port select --list gcc (NOTE: you probably won't have some of the later versions installed already. See next step)
Install latest version of gcc (gcc47 at the moment) with sudo port install gcc47 (this will take a while to download)
Run port select --list gcc again and you should see the new version in the list (eg. mp-gcc47)
Select this latest version as active gcc version with sudo port select gcc mp-gcc47
Run gcc -v again to check the latest version is active
With the compiler sorted, the first attempt to build rapidjson for release32 gave me errors about the limits header file due to __int128 not being defined for 32-bit builds`. Gnu's official position is that you need to roll your own. See answers at following link for more info:
Compiling 32bit binary: expected unqualified-id before '__int128'
Building for release64 or debug64 solved this issue, but it still failed to build due some warnings about casting away qualifiers in test/unittest/readertest.cpp:187:4. As the make file included the compiler flag -Werror=cast-qual, these warnings were treated as errors. Removing this flag in both unittest and perftest makefiles solved this issue (not ideal solution but I just wanted to get it building).
There were still linker warnings as the /usr/lib64 folder didn't exist, and the makefiles included the flag -L/usr/lib64, but the build was still successful.
SUCCESS - Both unittest_release_x64_gmake and perftest_release_x64_gmake ran without problems!
NOTE: rapidjson build instructions are included in the readme file in the ZIP archive.