Embedding SpiderMonkey JS - c++

I'm working on a C++ application. I would like to embed SpiderMonkey in the application.
I'm working with CMake, but I couldn't get that build. So, in an attempt to reduce complications, I tried the example code on this page. This wouldn't link using cmake or gcc from the command line.
So, even simpler, just to ensure I can link properly I am trying to get the following to work.
From the command line with gcc:
g++ --std=c++11
-I/home/thetasinner/moz/js/src/build_DBG.OBJ/dist/include
-L/home/thetasinner/moz/js/src/build_DBG.OBJ/js/src -DDEBUG
-Wl,--verbose -lmozjs-54a1 -lm -lz -ldl test.cpp -o test
On the following minimal code example:
#include <iostream>
#include <stdexcept>
#include "jsapi.h"
#include "js/Initialization.h"
int main(int argc, char** args) {
if (!JS_Init()) {
throw std::runtime_error("failed to initialise.");
}
std::cout << "It's alive!\n";
JS_ShutDown();
return 0;
}
Even this doesn't link. I get the errors
/tmp/ccqjx5RY.o: In function `main':
custom.cpp:(.text+0xf2): undefined reference to `JS_ShutDown()'
/tmp/ccqjx5RY.o: In function `JS_Init()':
custom.cpp:(.text._Z7JS_Initv[_Z7JS_Initv]+0xa): undefined reference to
'JS::detail::InitWithFailureDiagnostic(bool)'
collect2: error: ld returned 1 exit status
The headers are found and the linker is finding the mozjs library
attempt to open /home/thetasinner/moz/js/src/custom_build_DBG.OBJ/js/src
/libmozjs-54a1.so succeeded
-lmozjs-54a1 (/home/thetasinner/moz/js/src/custom_build_DBG.OBJ/js/src
/libmozjs-54a1.so)
I am working on Linux (Ubuntu 16.04 and Debian 8.7 tried) because that's where the build tools are. I don't even want to touch Window's yet.
The 'js' executable built in the spidermonkey build works fine, which I assume has the lib I'm trying to link inside it. So I would have thought the lib itself is built okay.
Can anybody help me resolve these linker errors? There are lots of answers to questions about much older versions of SpiderMonkey, but there's nothing for more recent versions. I'm interested in version 45 (which I've tried with very similar errors) or the tip version 52.
I'm comfortable enough digging around in the code working out how to do what I want with it once it builds, hence the interest in the latest version which isn't properly documented, I'm just completely stumped with the building step.

I suspect it's just an ordering problem on the command line:
g++ --std=c++11
-I/home/thetasinner/moz/js/src/build_DBG.OBJ/dist/include
-L/home/thetasinner/moz/js/src/build_DBG.OBJ/js/src -DDEBUG
test.cpp -o test
-Wl,--verbose -lmozjs-54a1 -lm -lz -ldl
Compilation first, followed by linking, with libraries in order of dependency. (My first guess was you'd neglected to mention mozjs on the command line. It took a second look to see it was just in the wrong place.)

Related

Cross compilation for gpsd shows "unrecognized option"

I am cross-compiling gpsd3.20 on my Ubuntu 16.04 for the ARM architecture. As you may know, gpsd uses Sconsctruct to compile the source codes. During my cross-compilation, the moment when it needs to create the libgps.so it shows an error unrecognized option '-Wl, -Bsymbolic'.
Before posting the question here, I have tried t check my toolchain binaries and I found out that if I run this line manually:
sudo ./arm-v7a-linux-gnueabihf-ld -o test/gpsd-3.20/libgps.so.25.0.0 -pthread -shared -Wl,-Bsymbolic-functions -Wl,-soname=libgps.so.25 test/gpsd-3.20/os_compat.os test/gpsd-3.20/rtcm2_json.os test/rtcm3_json.os test/gpsd-3.20/shared_json.os test/gpsd-3.20/timespec_str.os test/gpsd-3.20/libgpsmm.os -L. -lrt -lm -lrt
The above commands print out the exact error as I mentioned previously. However, if I run the exact command replacing ld with gcc, then there is no any errors.
sudo ./arm-v7a-linux-gnueabihf-gcc -o test/gpsd-3.20/libgps.so.25.0.0 -pthread -shared -Wl,-Bsymbolic-functions -Wl,-soname=libgps.so.25 test/gpsd-3.20/os_compat.os test/gpsd-3.20/rtcm2_json.os test/rtcm3_json.os test/gpsd-3.20/shared_json.os test/gpsd-3.20/timespec_str.os test/gpsd-3.20/libgpsmm.os -L. -lrt -lm -lrt
Upon checking the arm-v7a-linux-gnueabihf-gcc --help, I found out that, gcc support -Wloptions whereas in the arm-v7a-linux-gnueabihf-ld it doesn't support the -Wl options. So now I am not sure how to change the SConstruct file so that it doesn't execute ld instead I want it to execute gcc especially for the libgps.so part.
(can't comment), so as answer: have you tried to set the env.-var.:
export LD=arm-v7a-linux-gnuabihf-gcc
Gcc takes -Wl,XXX and passes XXX to the linker.
I think you've got two combining problems here, though there's some guessing involved without looking into the build itself. First, scons shouldn't be adding the flag when building a library (https://github.com/SCons/scons/issues/3248 - fixed but, I believe, not part of a release). Second, "linking" should probably be done using gcc. If you call gcc to link, it still calls the linker behind the scenes - after dealing with options that are intended for gcc, which -Wl,-Bsymbolic is, it means pass -Bsymbolic on to the linking phase (indicated by -Wl, the 'l' meaning linker). So I'm supposing that the way you've told scons about the cross toolchain isn't quite right either, if it's calling ld directly you're probably going to have other issues as well.

Set openmp in MKL Library

I am trying to compile a minimal C++ code
#include <iostream>
#include <mkl.h>
#include <omp.h>
int main(int argc, char *argv[])
{
omp_set_num_threads(4);
return 0;
}
using the MKL library (icc version 17.0.4) in a MacOSX Sierra 10.12.5, using the command
icc main.cpp -o main.o -DMKL_ILP64 -I/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/include \
-L/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/lib -Wl,-rpath,/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/lib -lmkl_intel_ilp64 \
-lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl
However I receive the following error when I run the program
dyld: Library not loaded: #rpath/libiomp5.dylib
Referenced from: /Users/user/C++/MKL1/./main.o
Reason: image not found
/bin/sh: line 1: 8898 Abort trap: 6 ./main.o
make: *** [run] Error 134
How to set up properly the openmpi with the MKL library? I tried to follow the instruction in https://software.intel.com/en-us/articles/dyld-library-not-loadedlibiomp5dylib?page=1#comment-1905809
by adding
source /opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/bin/mklvars.sh intel64
However I still get the same error during runtime.
I have tried a few ways to solve this issue. It literally took an entire day. But here are the results,
Project Files
I created a very simple Project with just one file, named,
test.c
1. The Easiest Solution
Fixing this can be as simple as,
icc -qopenmp -qopenmp-link=static test.c
This method just tells the compiler to link to static OpenMP run-time libraries.
Interestingly, the docs at Intel C++ Compiler Docs v.15 say that this is deprecated while Intel C++ Compiler Docs v.17 do not even mention about this argument, BUT it works. Probably they forgot to take it out.
2. Another method (which I do not recommend, nor do folks at Intel)
To compile the file you can use the normal "-qopenmp" flag
icc -qopenmp test.c
This creates the "a.out" file.
This method of fixing the error makes use of command-line utility called,
install_name_tool
Using this method we can change the path of #rpath/libiomp5.dylib
install_name_tool -change #rpath/libiomp5.dylib /opt/intel/compilers_and_libraries_2018.1.126/mac/compiler/lib/libiomp5.dylib a.out
Note: In place of compilers_and_libraries_2018.1.126 it should be your version of the compiler.
3. One of the BEST (correct) ways
You can just add
export DYLD_LIBRARY_PATH="/opt/intel/compilers_and_libraries_2018.1.126/mac/compiler/lib"
To your ~/.bash_profile
And then use the normal way of compiling,
icc -qopenmp test.c
Everything works perfectly.
Quick tip: You can use the otool command line utility to check the libraries your file links to.
otool -L a.out
I found the answer on https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/645194
Basically one has to add
-Wl,-rpath,/opt/intel/compilers_and_libraries_2017.4.181/mac/compiler/lib
during compilation. Now openmp with icc works perfectly

GoogleTest: CLang error compiling ASSERT_FALSE(false)

I downloaded googletest and built it in a subdirectory named build.
Then, I wrote the following code in a file named main.cpp:
#include <gtest/gtest.h>
TEST(FOO, BAR) { ASSERT_FALSE(false); }
Quite simple indeed.
It relies on the fact that a main function is already provided with googletest if you link the libgtestmain.a library.
GCC (v5.3.1) compiles it using the following command:
g++ -L./googletest/build/googlemock/gtest -L./googletest/build/googlemock -I./googletest/googletest/include/ -lgmock -lgtest -lgtest_main -lgmock_main -pthread -std=c++11 main.cpp
Anyway, clang (v3.6.2) does not compile using the same command:
clang++ -L./googletest/build/googlemock/gtest -L./googletest/build/googlemock -I./googletest/googletest/include/ -lgmock -lgtest -lgtest_main -lgmock_main -pthread -std=c++11 main.cpp
The error is the following one:
/tmp/main-4127ae.o: In function 'FOO_BAR_Test::TestBody()':
main.cpp:(.text+0x7b): undefined reference to `testing::internal::GetBoolAssertionFailureMessage(testing::AssertionResult const&, char const*, char const*, char const*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The code contains almost the sole ASSERT_FALSE(false) statement (that's a minimal, complete example and still it doesn't compile), so I'd say that the problem is not in the code itself.
The same problem arises also from the following statement:
TEST(FOO, BAR) { ASSERT_TRUE(true); }
Is that an issue due to googletest, to clang or whatever?
I'm trying to figure it out, but I'm a little bit in trouble while looking at the code of googletest.
NOTE
I've not been able to find neither an open nor a closed issue for googletest, so I'm to open also a ticket for it on github.
In a while I'll probably post the link to the issue.
As of GCC 5.1, g++ is not ABI-compatible with clang++. Some
bug reports: clang++ no longer ABI-compatible with g++
and Add support for gcc's attribute abi_tag (needed for compatibility with gcc 5's libstdc++).
Till this is fixed you need to link googletest-ing projects
with googletest libraries built with the same compiler.

Undefined reference to boost::random::random_device constructor and destructor on MinGW-w64 gcc

My OS is Windows 7 64-bit and C++ compiler I'm using is:
g++ (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 5.3.0
And I installed Boost version 1.60 using:
bootstrap.bat mingw
b2 install target=gcc
Then I tested is it working, using examples from Boost.Random tutorial.
With the first two everything was fine, but the third one gave linker errors about boost::random::random_device. I minimized the code to have only this:
// Compiled with:
// g++ -IC:/Boost/include/boost-1_60
// -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
// main.cpp
#include "boost/random/random_device.hpp"
int main() {
boost::random::random_device rng;
}
And I get the following errors:
C:\Users\Daniel\AppData\Local\Temp\cc5DfdjZ.o:main.cpp:(.text+0x15):
undefined reference to `boost::random::random_device::random_device()'
C:\Users\Daniel\AppData\Local\Temp\cc5DfdjZ.o:main.cpp:(.text+0x20):
undefined reference to `boost::random::random_device::~random_device()'
collect2.exe: error: ld returned 1 exit status
Here, on SO, I found that someone with similar problem added -lboost_system to flags, but for me it didn't helped.
Does anyone have any idea, why it isn't working? I checked, and I have random_device.hpp header in my Boost folder, with declarations of random_device() and ~random_device() in it.
I found what was wrong - the g++ command syntax, that I wanted to use to compile and link my code.
As I wrote in my question, I do this that way:
g++ -IC:/Boost/include/boost-1_60 -LC:/Boost/lib -lboost_random-mgw53-mt-1_60 main.cpp
While the correct one is with main.cpp (or any other source code file(s), that we want to include in compiling process) before the -L and -l flags.
For example:
g++ -IC:/Boost/include/boost-1_60 main.cpp -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
or even
g++ main.cpp -IC:/Boost/include/boost-1_60 -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
Hope it will help anyone, who will make such silly mistake too.

Static linking to libcrypto++, with g++

I am trying to compile a program on my system with Debian Wheezy and g++4.7. I want it to be able to run on another system with Debian Squeeze (and no recent g++). I can't compile the program on the Squeeze, because I use certain C++11 features the old g++ does not support, as well as a new Boost version and libcrypto++9.
As far as I understand the usual way to get around this problem is to static link the libraries not supported at the other system, in my case libstdc, boost and crypto++.
My (linking) compiler call right now is
g++-4.7 .obj/btcmirco.o -Wl,-Bstatic -lboost_program_options -lboost_system -lcrypto++ -Wl,-Bdynamic -lcurl -static-libgcc -std=c++11 -o MyProgram
However I seem to have missed something, because it throws a lot of undefined reference errors. It works fine if I dynamic link to crypto++ (and only static link libstdc and boost).
Can anyone tell me whats wrong, or if there is a fundamental error in my approach?
The linker errors I get are (shorted):
`.text._ZN8CryptoPP22BufferedTransformationD2Ev' referenced in section `.text._ZN8CryptoPP22BufferedTransformationD1Ev[_ZN8CryptoPP22BufferedTransformationD1Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o): defined in discarded section `.text._ZN8CryptoPP22BufferedTransformationD2Ev[_ZN8CryptoPP22BufferedTransformationD5Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o)
`.text._ZN8CryptoPP25MessageAuthenticationCodeD2Ev' referenced in section `.text._ZN8CryptoPP25MessageAuthenticationCodeD1Ev[_ZN8CryptoPP25MessageAuthenticationCodeD1Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o): defined in discarded section `.text._ZN8CryptoPP25MessageAuthenticationCodeD2Ev[_ZN8CryptoPP25MessageAuthenticationCodeD5Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o)
I experienced the same problem and this has to do with the fact that you are trying to mix code generated by g++-4.7 (your program) with code generated by a previous version of g++ (cryptopp library).
The reason behind this is that when you execute compile the library executing make command, it uses the default version of g++ set up for your system, usually the one that comes with the OS.
In order to solve the issue what you should do is compile cryptopp library with g++-4.7.
For that, compile the library by executing make CXX=g++-4.7. The resulting static library shouldn't give you the error when being linked with your code.