Sorry about english mistakes) Please help. I try build v8 engine from "Hellow world" example. It will be embedded on my base project, so i am need build it with Cmake, (system is macOS Sierra). I compiled v8 engine (build libraries by default stored in out directory) and i have following file system structure:
screen file system
As showed in example it later most build with this make expression :
g++ -I. hello_world.cpp -o hello_world -Wl,--start-group out/x64.release/obj.target/{tools/gyp/libv8_{base,libbase,external_snapshot,libplatform},third_party/icu/libicu{uc,i18n,data}}.a -Wl,--end-group -lrt -ldl -pthread -std=c++0x
also, please look at my CMakeLists.txt file:
screen CMakeLists.txt
On build i have the following error output:
ld: symbol(s) not found for architecture x86_64
I solved problem, and for future i write my steps, how build V8 on macOS:
Build v8 engine without snapshot and as shared library for native platform: sudo make library=shared snapshot=off native;
Compile with clang (gcc throw error, like "undefined symbol for architecture..." etc ) but clang on mac compiles fine;
Copy from your ./out directory files with *./dylib to usr/local/lib
Related
I am trying to cross-compile Windows software on Linux using mingw32-w64 and running it with wine. However wine cannot load the libstdc++-6.dll library file. I searched online and found out that you have to put the directory that contains the DLL file into the path registry. In my case, that directory is Z:\bin\i686-w64-mingw32\bin.
Then I tried to run the compiled file by using wine executable.exe and the output is:
0100:err:module:import_dll Loading library libstdc++-6.dll (which is needed by L"Z:\\home\\sunnymonster\\dev\\c++\\opengl-tests\\cmake-build-debug\\opengl_tests.exe") failed (error c000007b).
0100:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\sunnymonster\\dev\\c++\\opengl-tests\\cmake-build-debug\\opengl_tests.exe" failed, status c0000135
I have verified that I am using the correct wine prefix.
Additional information:
Linux distro: Manjaro Linux 21.2.5
Linux kernel: 5.16.14-1
There're multiple approaches. First, let's formalize the problem:
$ cat test.cpp
#include <iostream>
int main() { std::cout << "hello" << std::endl; }
$ i686-w64-mingw32-g++ test.cpp -o a && WINEDEBUG=-all,err+module wine ./a.exe
0024:err:module:import_dll Library libgcc_s_dw2-1.dll (which is needed by L"Z:\\tmp\\a.exe") not found
0024:err:module:import_dll Library libstdc++-6.dll (which is needed by L"Z:\\tmp\\a.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"Z:\\tmp\\a.exe" failed, status c0000135
Solutions:
Link the core libraries statically:
$ i686-w64-mingw32-g++ test.cpp -o a -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic
$ WINEDEBUG=-all,err+module wine ./a.exe
hello
Use WINEPATH env. variable to tell wine the additional paths to load dlls from. In the example I pass it the location with mingw dlls that wine complains about. It may be different on your system, you might find it by asking package manager to list files in mingw-g++/gcc packages (whatever it's called on your system). Multiple paths should be separated by semicolon.
$ i686-w64-mingw32-g++ test.cpp -o a
$ WINEDEBUG=-all,err+module WINEPATH=/usr/i686-w64-mingw32/sys-root/mingw/bin/ wine ./a.exe
hello
Install a Windows version of MinGW, and then use it to compile the app. However, from what I remember, if you want to distribute the executable produced, you still need to either statically link against MinGW libs, or provide them together with the binary. So the only difference to point 1 is that the binary should work under your WINEPREFIX with no modifications.
Using wineg++. I mention it solely for completeness, I think it's the least useful solution. It produces a Linux file, which in itself might be okay, one could use that for debugging. However, in my tests, I didn't manage to makewineg++ link against a dll, even though mingw links to the same dll without a problem. It seems to link against .so files instead, even though the application you build with it can load .dll files dynamically. Odd utility.
$ wineg++ test.cpp -o a
$ WINEDEBUG=-all,err+module wine ./a.exe
hello
UPDATE
I've sorted this by explicitly adding the appropriate -I and -L options, but I'm curious as to why this is necessary now when it wasn't before? On the plus side those annoying library out-of-sync warnings are gone.
UPDATE ENDS
I've broken my OSX OpenGL build environment. I'm building from terminal (using make) with g++, for example:
g++ -o myprog main.o -lglfw -lglew -framework OpenGL
and getting errors:
ld: library not found for -lglfw clang: error: linker command failed with exit code 1 (use -v to see invocation)
These are in addition to compiler errors such as:
g++ -c main.cpp main.cpp:3:10: fatal error: 'GL/glew.h' file not found
So it seems the OpenGL libraries and includes have been lost. Everything was working fine until I executed the command:
export SDKROOT="$(xcode-select -p)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
Which I did to try and fix warning messages like:
ld: warning: text-based stub file /System/Library/Frameworks//OpenGL.framework/OpenGL.tbd and library file /System/Library/Frameworks//OpenGL.framework/OpenGL are out of sync. Falling back to library file for linking.
I got that 'fix' from here: macOS framework lib problem
I realise it was reckless running commands that I don't fully understand but nonetheless... now I can't compile/link any OpenGL code and after scouring the internet for help I've come up with nothing, so here I am.
I'm running OSX 10.13.6 on a 2013 MacBook Pro.
First post BTW so please forgive me if I've not provided enough detail.
I have build the poco library in solaris. My system configuration is SunOS solaris2 5.10 Generic_144488-07 sun4v sparc SUNW,SPARC-Enterprise-T1000. When I tried to run the sample which was provided along with the sample I am able to build and run the sample application. But when I wrote a seperate program and tried to link with poco library, I am getting the following error
ld: fatal: file /74bkp/ramesh/poco-1.4.7p1/lib/SunOS/sun4v/libPocoXML.so: wrong ELF class: ELFCLASS32
ld: fatal: file /74bkp/ramesh/poco-1.4.7p1/lib/SunOS/sun4v/libPocoFoundation.so: wrong ELF class: ELFCLASS32
I use the following command to compile the source
g++ -I/74bkp/ramesh/poco-1.4.7p1/XML/include -I/74bkp/ramesh/poco-1.4.7p1/Foundation/include -L/74bkp/ramesh/poco-1.4.7p1/lib/SunOS/sun4v DOMParser.cpp -lPocoXML -lPocoFoundation -m64
Can some one please give a clue. I could not move further.
regards,
Sam Mouli
You have built 32-bit binaries of Poco, therefore you cannot link them to 64-bit binaries.
Remove the -m64 option from the compiler call and optionally add -m32, then it should work. Alternatively, build 64-bit binaries of Poco and link to them.
I am trying to compile a simple tutorial program utilising glfw with minimal opengl. My issue appears to be that the glfw library is stubbornly refusing to be dynamically linked. The relevant make command is:
"C:\Program Files\mingw-w64\mingw64\bin\g++" -Wall -m64 -D GLFW_DLL -l opengl32 -l glfw3 main.o -o triangle <br />
The main.o file is compiled from a c++ file, main.cpp by:
"C:\Program Files\mingw-w64\mingw64\bin\g++" -c -Wall -m64 -D GLFW_DLL main.cpp -o main.o
Every reference to the glfw functions made inside the code is causing an undefined reference to the relevant implementation functions (eg. __imp_glfwInit for glfwInit => undefined reference to '__imp_glfwInit')
Build system is mingw-w64 [windows] using make via the command line, with glfw 3.0.4. The glfw lib is 64 bit and the latest stable build avaliable. It consists of the files:
glfw3.dll
glfw3dll.a
libglfw3.a
Which are the 'WIN-64' 'lib-mingw'
After extensive searches (GLFW help pages useless[deal either with 2.7.2 which doesn't apply or doesn't have useful information in the case of 3.0.4], most of stackoverflow deals with static linking, ect) I have been unable to find a solution which works.
Is there something I am missing dealing with the linker that is not making me able to dynamically link?
Clarification on any errors I am making or a solution of some form that would still allow me to use the dynamic libraries would be greatly appreciated
It appears that the provided files do not work with mingw-w64, and are only compatible with 64bit mingw.
Thus the only option left is linking against the dll (with thanks to greatwolf: https://stackoverflow.com/a/17734362/2396393). The code to compile to objects thus became:
"C:\Program Files\mingw-w64\mingw64\bin\g++" -Wall -m64 -D GLFW_DLL main.o -o triangle ./lib/glfw3.dll -l opengl32
Where the dll glfw3 is located in the lib folder
I'm trying to call R from c++ on linux via RInside, I compiled R-2.15.1 from source with gcc version 4.5.3 (Debian 4.5.3-1) , I don't have sudo rights to use apt-get install. I'm using OpenBlas and a system optimized lapack. The blas and lapack libraries work fine for many scalapack applications
I installed R with
./configure --with-blas="-I/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/include -L/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/lib -lopenblas -lgfortran" --with-lapack="/usr/lib/liblapack.so -lgfortran" --enable-BLAS-shlib=yes --enable-R-shlib --enable-R-static-lib --prefix= .
which installed and runs fine,I ran make check with no errors, also all the packages (Rcpp and RInside) installed fine..
however when i use the given RInside makefile , the basic hello world example from /standard/rinside_sample0.cpp compiles! but it does not run and i get the following error
./rinside_sample0: error while loading shared libraries: libRblas.so: cannot open shared object file: No such file or directory
the file libRblas.so exists and is in the R/lib folder,
when i try to link it manually with the g++ command the make file creates or linking as follows i get a segmentation fault
/R/lib/libRblas.so ./hello_world
Segmentation fault
EDIT: heres how the example make file tries to compile an example, (which compiles fine) but won't run with the above missing libRblas.so error
g++ -I/nfs/user03/jimmie21/libs/lib64/R/include -I/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/include -I/nfs/user03/jimmie21/libs/lib64/R/library/RInside/include -g -O2 -Wall -I/usr/local/include hello_world.cpp -L/nfs/user03/jimmie21/libs/lib64/R/lib -lR -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRlapack -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -lRcpp -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -L/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -lRInside -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -o hello_world
Couple of things:
Reproducible examples, please
You have a non-standard setup
With the script from 1), try it on a standard setting as that is how Rcpp / RInside get developed and tested (on Ubuntu / Debian)
The Rcpp test suite now contains almost 800 unit tests from around 350 unit test functions. These do not seg.fault, so the issue is at your end. Similarly, RInside has dozens of examples in the four examples/ subdirectories. This also works.
It may be as easy as tweaking the Makefile / Makevars files to make sure you get your libraries in all cases. But we can't tell as there is nothing reproducible here.
Edit If you want to link with libRblas.so then you have a completely non-standard setup as the R packages for Debian / Ubuntu as use the external BLAS. Again, not an RInside issue.
I fixed the problem by adding the R install path lib ../R/lib: to the beginning of LD_LIBRARY_PATH after that all the examples compiled and run fine