So I compiled the assimp library with cmake using the x64_x86 developer command prompt that was said to be required. (When I tried using the regular console cmake did an error that it could not find 'the cl compiler').
After some time it finally compiled without errors with the following commands:
cmake CMakeLists.txt -DASSIMP_BUILD_ASSIMP_TOOLS=OFF
cmake --build .
It built 3 files:
C static library zlibstaticd.lib
CXX shared library ..\bin\assimp-vc142-mtd.dll
CXX executable ..\bin\unit.exe
But there was no libassimp.a or libassimp.so that I can link against in MinGW. I tried just linking with te dll in my own project with:
-L\"{assimp root directory}/bin\"
-lassimp-vc142-mtd
and it failed with "undefined reference to `Assimp::Importer::Importer()"
How can i get the lib file to link against?
I installed MSYS2, replaced my existing MinGW installation with MSYS, libraries installed flawlessly and everything works now.
My mistake was that:
I was compiling the library with VS C++ toolkit while I'm compiling my project with MInGW make and g++
even after I compiled assimp the correct way, version 5.2.4 couldn't find some header, 5.2.3 and some older versions compiled successfully, but failed some unit tests (God knows why). Seemed to always hit some unresolved issue on GitHub. Never again compiling libraries from source.
Hello I've got my first program using opus-codec library and I wonder if there is another way to compile it without passing by cmake. Such as the g++ command for example. Which flags should I use ?
cmake is not a compiler, it is a tool for managing the build process. To compile your files, you are already using a compiler (g++ may be) which is called by the build files created by cmake.
For example when you run cmake command on a linux, you will generate a Makefile. The when you run your make command it will call gcc or g++. To see the compilation commands, you can add VERBOSE=1 to your make command.
as far as I know, objcopy is able to move debug symbols (compiled with -g flag) outside from an executable binary. I found this question, but there are only generic methods for symbol outsourcing.
But what can I do when my executable is using some really large .so and .a files?
I would like to profile my application in a small environment where is not enough place for the debug symbols. The entire project was built with -g option. The debug symbols are needed later only when the profile log is processed.
You can strip debug symbols:
strip --strip-debug object.so
I have been trying to find a way to get Clang working on Windows but am having trouble. I get Clang to compile successfully, but when I try to compile a program I have a bunch of errors in the standard headers.
I am aware of rubenvb's excellent prebuilt versions of clang, but I want to compile it for myself. I also was listening to the GoingNative talks about clang which said that it didn't have very good Windows support yet. How can I get clang working on Windows?
I used the following method to compile clang for C++ on Windows 7 and it has been validated by Mysticial and others:
Download and install MinGW (make sure you install the C++ compiler) and put the bin folder in your PATH (I have MinGW 4.6.1 and tested successfully on another computer with 4.6.2)
Make sure you have Python in your PATH (not 3, I have 2.7)
(Optional: Make sure you have Perl in your PATH (I used ActivePerl 5.14.2 64-bit))
Get CMake and put it in your PATH
Go to the LLVM downloads page and download the LLVM 3.0 source code along with the Clang source code. Don't get the code from the SVN, it doesn't work with the MinGW headers.
Extract the source codes; I had the llvm source in a folder named llvm-3.0.src on my desktop
Put the clang source directly in a folder called "clang" (it must be called this exactly or you will build llvm but clang won't get built) in the "tools" folder inside the llvm source folder, this should make your directories look like:
llvm source
autoconf folder
...
tools folder
...
clang folder
bindings folder
...
Makefile file
...
...
...
Make a folder named "build" in the same directory as the llvm source folder
Open a command line and cd into the build folder
Run the command cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release ..\llvm-3.0.src
(the last argument is the relative path to the folder that has the llvm source in it (and the clang source in the tools/clang subdirectory))
This will do the equivalent of a "configure" command, and the makefiles and everything will be generated in the build folder
This will take a few minutes
Run the command mingw32-make
This will compile llvm and clang, and the clang executables will be generated in the build/bin folder
This will probably take a long time. (You can try to speed it up by adding parallel builds, -j<number> option) It might be good to close all other programs so that your computer can concentrate, and so they don't interfere with the lengthy compilation process, such as putting a lock on a folder that the compiler is writing to (it happened to me). I even turned off my antivirus and firewall software so that they wouldn't try to scan the generated files and get in the way.
Time for testing it out
Create a .cpp file in the build/bin folder (I will use hello.cpp). Use a standard library header to make sure the include paths and libraries are working. Start with a very simple program.
(What I started with:
#include <iostream>
int main() {
std::cout << "hi";
}
)
Run the command clang hello.cpp -std=c++0x -I"C:\MinGW\lib\gcc\mingw32\4.6.1\include\c++" -I"C:\MinGW\lib\gcc\mingw32\4.6.1\include\c++\mingw32" -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.1 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../.. -L/mingw/lib -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt
(-L specifies a directory in which to search for libraries and -l specifies a library to link)
(If you do not have MinGW installed to the same path as I did, you can find out the paths with the command "g++ somefile.cpp -v" to get g++ to spill its guts about what options it is using for the library paths and library files and everything else
Search near the end of the output for the -L and -l options. Be aware of the .o file names that are interspersed with the -L's. Clang uses many of the same options as g++ so I literally copied and pasted that line from the output of g++)
This should compile your program and produce a file named a.out
rename a.out to a.exe or whatever
Run the .exe
Your program should run.
Clang (3.0) still has some problems on Windows (I don't know if these problems are also on linux). For example, compiling a lambda (which clang doesn't support) with -std=c++0x will cause clang to crash and emit a diagnostic error.
(I was informed on the LLVM IRC that this is because clang implements parsing for lambdas but not semantic analysis, which is the phase in which it crashes (because they forgot to disable parsing lambdas for the 3.0 release), and they already know about this bug)
Also, the illustrious Mysticial kindly agreed to test this guide and made some observations during his testing:
Windows headers seem to work.
Currently only works for 32-bit.
64-bit compiles fine, but won't assemble.
SSE probably is fine. ([Mysticial hasn't] tested a working SSE on 32-bit though.)
Here is what worked in my environment, on Windows 8.1, overall similar to Seth's instruction, but with fresher tools.
I installed MinGW 64 into C:/MinGW, to be precise I've used STL's distro.
I installed Python 3, just took their latest version.
I installed CMake 3.0.2
I forked LLVM and Clang on Github and cloned them to my machine, placing Clang's repo into llvm\tools\clang folder (the structure is described on the official page, they just show examples with svn instead of git).
I created "build" folder next to "llvm" folder, and inside the "build" folder ran this command: cmake -G "MinGW Makefiles" -D"CMAKE_MAKE_PROGRAM:FILEPATH=C:/MinGW/bin/make.exe" -DCMAKE_BUILD_TYPE=Release ..\llvm (for some reason CMake couldn't find the "make" automatically)
Then I ran "make" to actually build. The build took a couple of hours.
After that in another folder I've created 1.cpp, which executes a lambda expression to print "hi":
#include <iostream>
int main() {
[]{ std::cout << "hi"; }();
}
I've also created a cmd file to compile the cpp. Alternatively you can just set the PATH variable properly via other means. Note that GCC vesrion in your MinGW package may be different. Also Clang has some builtin paths it tries, but they are tied to specific GCC versions, and mine was not among them, so I had to provide the include paths explicitly.
set PATH=<path to the build folder from step 5>/bin;c:/mingw/bin;%PATH%
clang++ -std=c++11 1.cpp -o 1.exe -I"C:/MinGW/include"
-I"C:/MinGW/include/c++/4.9.1" -I"C:\MinGW\include\c++\4.9.1\x86_64-w64-mingw32" -I"C:\MinGW\x86_64-w64-mingw32\include"
Running that cmd compiled 1.cpp into 1.exe that printed "hi".
What did not work:
I've tried building the same llvm+clang sources without MinGW+GCC using the MSVC compiler from VS 2015 CTP. It built Clang successfully, the only difference is that you need to do that from the Developer CMD window, and you'd need to run cmake -G "Visual Studio 12" ..\llvm and then compile the solution in Visual Studio. However, that Clang failed to compile a sample cpp, it complained about "undeclared identifier 'char16_t'" and "__int128 is not supported on this target" within the MinGW standard library headers. If I use clang-cl and MS STL headers it complains about "throw x(y)" specifiers . Maybe I needed to provide some extra keys to the build, but I couldn't get it to work.
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\xiosbase(293,4) : error: cannot compile this throw expression yet _THROW_NCEE(failure, "ios_base::eofbit set");
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\xstddef(56,30) : note: expanded from macro '_THROW_NCEE' #define _THROW_NCEE(x, y) throw x(y)
Refer http://clang.llvm.org/get_started.html#buildWindows
I've used "Visual Studio 11 Win64" with cmake and its worked with the currently available VS Express for Desktop.
Also for lib I'm using MinGW-W 64 and for missing files SUA. http://mingw-w64.sourceforge.net/ and http://www.suacommunity.com/
For linking .o compiled by clang++ for use with the W 64 binaries, I use -m i386pep with ld linker again shipped within the W 64 deliverable.
I had numerous problems building LLVM and clang using VS and being a Unix user I prefer building sources from the command line.
Following the instructions from Seth Carnegie I built it from the SVN repository as opposed to the supplied packages, using LLVM v3.3 with MinGW v4.5.2.
clang on Windows is NOT stand-alone, and it needs to be combined with another compiler (like MingW or MSVC).
The steps to do said combination are rather complicated, at least if you don't want to miss anything, hence the "build script" is worth an entire project:
https://github.com/mstorsjo/llvm-mingw
I have tested llvm-mingw project's version 20220906 (at time of writting, latest version), and it combines clang 15.0.0 with MingW seamlessly.
See pre-built binary releases:
https://github.com/mstorsjo/llvm-mingw/releases
Or try what worked for me:
https://github.com/mstorsjo/llvm-mingw/releases/download/20220906/llvm-mingw-20220906-msvcrt-i686.zip
I've got a c++ project (open source) that does not need to strip debugging symbols by default. With a lot of test executables, there are a lot of dSYM files generated on OS X. I've tried -g3 as a g++ flag to no avail. Ideas?
Thanks!
Juan
If you're compiling with the "-g" flag, remove it.
As Ted Mielczarek pointed out, gcc does not produce dSYM files on its own, it simply stores the information needed to produce them in the object files. If you're using make to build your project, it is most likely that there is a separate step in the makefile which runs dsymutil after compiling/linking the executable, see if you can find and remove it.
Are you compiling via XCode? GCC does not produce .dSYM files, XCode runs dsyumutil to generate them. In my (outdated) XCode 3.2.3, under Project Settings, Build Options -> Debug Information Format, you can choose "DWARF with dSYM File" or just "DWARF". The latter should not result in a dSYM being produced.
However, note that with Apple's toolchain, the DWARF resides in the .o files, and does not get linked into the final binary. (GDB knows how to find it, but it needs the .o files laying around on disk.) If you intend to send the binaries to someone else, you really do need to produce a dSYM to send them along with the binary.