I cannot compile anything with the current version of emscripten from the ubuntu repos
Here is the error
http://pastebin.com/j5Z0ztTs
I suspect it might be because emscripten is outdated in the repos, but why is there no bug reports??
Could anyone help? I cannot find any updated information.
Thanks in advance.
The reason is because you are using the /usr/bin/clang++ that comes with your Linux distribution.
This version does not support Javascript backend. In order to use emscripten, you have to compile fastcomp (an LLVM clang compiler with Javascript backend added)
If you have not built fastcomp yet, Emscripten won't work.
Check out this page for installation instructions:
http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
If you have already built fastcomp, then the problem is in your emscriptenrc file, and moreover your PATH.
This is how I worked around the issue:
I created a file called emscriptenrc.sh that did this:
export PATH=/home/mike/emscripten/fastcomp/build/master/bin:/home/mike/emscripten/fastcomp/build/master/include:/home/mike/emscripten/fastcomp/build/master/lib:$PATH
then after I created that file
I rebuilt the ~/.emscripten configuration file by calling
./emcc -v from the emscripten build directory -- this seemed to get the right version of clang registered...
now you can go ahead and compile with emcc
I would suggest reading http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
as well as the rest of the documentation prior to trying to use emscripten.
Related
I am learning LLVMand C++, but I find it hard to import LLVM into my project.
The first problem is my system has already installed clang and clang++ in usr/bin, but the other LLVM which was installed by brew is in /opt/homebrew/opt/llvm, is ok to delete clang in usr/bin and add opt/homebrew/opt/llvm/bin to env variable?
The second problem is how to link LLVM to my VSCode project, I try link LLVM by
#include "/opt/homebrew/opt/llvm/include/llvm/IR/Constants.h"
but it can't work.
Thanks for any help !!!
Never delete system utilities. Of any kind. For any reason.
Read the information presented to you in brew info llvm. This information was shown to you when you installed it.
Don't #include absolute paths.
Learn how to use compiler/linker flags to tell your compiler where to find headers/libraries.
Read the libc++ documentation to learn how to specify a specific libc++.
Finally, use a tool like cmake to automate this for you.
A homespun makefile might be sufficient.
What you are attempting to do is highly non-trivial. As one of the comments suggests, I would also recommend getting familiar with what's baked in before you try switching to a custom version.
So I just recently downloaded a C++ IDE called Code::Blocks and made a new project. But when I tried to Build and Run it, the code gave some errors. I know that it isn't a problem with syntax or anything like that because I ran the default code that Code::Blocks provided. The error is the following:
Project/Target: "firstcpp - Debug":
The compiler's setup (GNU GCC Compiler) is invalid, so Code::Blocks cannot find/run the compiler.
Probably the toolchain path within the compiler options is not setup correctly?!
Do you have a compiler installed?
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Compiler->Toolchain executables" and fix the compiler's setup.
Tried to run compiler executable 'C:\MinGW/bin/gcc.exe', but failed!
Skipping...
Nothing to be done (all items are up-to-date).
It seems to me like there is some kind of issue with the C++ compiler, but I thought Code::Blocks already came with a C++ compiler, so I'm not too sure what the issue here. I also followed their instructions to go to Settings->Compiler...->Global compiler settings->GNU GCC Compiler->Toolchain executables, but I'm not too sure what they mean by fix the compiler. Here is a screenshot of what I'm seeing:
Also here's info on my PC if you need it:
At this point I'm not too sure what to do to fix this problem. I have asked my friends about this problem(they have already successfully downloaded and used Code::Blocks), and they said that they never encountered this problem while they were installing it.
You need to ensure that you have a working installation of the GNU Compiler Collection, and that the paths you select for your toolchain exist.
If you don't already have GCC Installed, the easiest way would be to download a Code::Blocks distribution that comes pre-bundled with MinGW from the download site. However, it's also possible for you to install GCC through other means, such as:
Installing GCC with MinGW through msys2, or
Installing GCC with scoop install gcc on Windows
In either case, you need to select the installation path that contains the bin directory when setting up the toolchain in Code::Blocks.
In case you didn't notice, C::B formed the path to compiler with both "\" back slashes and "/" slashes, which simply isn't a valid Windows path !!
Slashes are used in Linux not Windows! But for some reason C::B is not getting this. And probably your Mingw is well set !!
C:\MinGW/bin/gcc.exe should be C:\MinGW\bin\gcc.exe
I had pretty hard time trying to fix this in win 7 32 bit/C::B version 20.03 but with no success, i checked all available options and settings, and actually i started to think that it's a bug.
I'm trying to use the Canon EDSDK (latest version, v3.6 as of writing) in a simple, C++, command-line program on macOS (Sierra 10.12.6). I wish to utilize a simple Makefile environment and the usual apple compiler tools (llvm-clang) and avoid Xcode or any other heavy-weight IDE. The samples included with the SDK are all Xcode centric so I've had to roll my own here.
At present, I am able to compile a program to init the SDK and list connected cameras. As soon as I execute any EDSDK command however, I am getting a dynamic linking error:
Error loading /Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG: dlopen(/Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG, 262): no suitable image found
Did find: ... snip ... mach-o, but wrong architecture
The same error lists twice (both for DppCoreG). Upon examination, DppCoreG is compiled for 64bit architecture:
file /Library/Frameworks/..snip../DppCoreG
/Library/Frameworks/..snip../DppCoreG: Mach-O 64-bit bundle x86_64
However, there are other critical parts of the EDSDK that are compiled for 32bit architecture only:
file /...snip.../DPP.framework/DPP
/...snip.../DPP.framework/DPP: Mach-O dynamically linked shared library i386
How do I resolve this? The path of least resistance so far is to compile to i386 architecture explicitly (and the documentation explicitly states EDSDK is not 64-bit compatible). All is well except this one dynamic linking error (and in fact everything I've tried so far, which is just listing connected cameras, seems to work okay) but it is something I'm sure I can't continue to ignore or allow to persist in a production version of this project.
Here's a minimal example to cause the DYLD error:
#include <EDSDK.h>
#include <EDSDKTypes.h>
#include <EDSDKErrors.h>
int main(int argc, char** argv) {
EdsInitializeSDK();
EdsTerminateSDK();
return 0;
}
And probably more informative is the command to compile:
c++ -D __MACOS__ -g -arch i386 -I./deps/mac/include -framework DPP -framework EDSDK -o min min.cpp
I have the headers in the local include directory shown in the command and the frameworks installed under /Library/Frameworks.
Note that the c++ command is Apple LLVM version 8.1.0 (clang-802.0.42)
I've concluded that this is just an error on the part of those that deliver the EDSDK for mac. They should be compiling this particular bundle as a universal binary, not a 64bit binary. You can work around the problem by simply removing the offending bundle. It appears to just be a plugin and removing it does not seem to immediately affect the SDK. Assuming you have installed the EDSDK framework in /Library/Frameworks then just do this:
sudo rm -rf /Library/Frameworks/EDSDK.framework/Versions/Current/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle
Enter your password when prompted (this assumes you are an admin account) and it will delete the offending plugin.
I have to believe that there may be consequences for removing this plugin at some point and if anyone knows more about this particular bundle/plugin and can explain what removing it will do I'd appreciate the additional insight.
In addition to #OllieBrown answer, I found in Xcode building for MacOS I had an additional item to remove to stop the link warnings.
link warning- EDSDK.framework/Versions/Current/DPPLibCom.bundle/Contents/MacOS/DPPLibCom: mach-o, but wrong architecture
removing EDSDK.framework/Versions/Current/DppLibCom.bundle stopped the warning.
Since the 3.x version there is a split between intergrated versions of DPP RAW capabilities. The original DPP works in x86 mode only and allows inspection and conversion of CR2 files on cams up until a certain models. See the API doc for the list. For recent camera models which rely on the new 64bit DPP engine (v4+?, dppcoreg) you would need x86_64 bit build so it dynamically links to use the latest features. Quite some (Raw) features are dropped, and gradually make their way back in in beta state.
I have installed the latest LLVM svn trunk using cmake (this is the first time I have used cmake to build LLVM).
The problem is that when I try to make the Hello pass from the LLVM tutorial, it compiles fine (a .so file is created), but the opt tool is unable to load it. It fails with the following message
$ opt -load ./Hello/libLLVMHello2.so
Error opening './Hello/libLLVMHello2.so': ./Hello/libLLVMHello2.so: undefined symbol: _ZTIN4llvm12FunctionPassE
-load request ignored.
I am using cmake, and following the instructions at http://llvm.org/docs/CMake.html#cmake-out-of-source-pass
I have some other passes lying around, but I do not want to use the cmake build system until this problem is solved.
Any suggestions would be helpful. Thank you!
You built your Hello pass with rtti enabled, while LLVM is built without.
I have:
- OS: WIndows 7
- MinGW, gcc 4.8.0.
- MSYS 7.2
- Dowloaded log4cplus-1.1.1 from it's website .
./configure - done well.
But at "make" I receive error with message "undefined reference Mutex::Mutex(Mutex::type)". I searched for ctors for that class inside code, it can be found at:
log4cplus-1.1.1\include\log4cplus\thread\syncprims-pub-impl.h
log4cplus-1.1.1\include\log4cplus\thread\impl\syncprims-pthreads.h
log4cplus-1.1.1\include\log4cplus\thread\impl\syncprims-win32.h
But I don't know how to order comlier use any of them. I checked in MakeFile, they included as include files, I added to config.cxx define WIN32, that still don't work.
How to order my compiler compile log4cplus correctly?
Please try the patch attached to ticket #282. This should be fixed on 1.1.x branch already.