I have a project that has a bunch of .c files that need to be compiled as C files, but I need one of them to be compiled as C++ code.
I tried the solution found here but it did not work as expected. Instead of making only filename.c be compiled as C++, it compiles all the files in my project as C++ code. Without that call, all files are compiled as C.
I even tried this:
set_source_files_properties(${FILES_SRC} PROPERTIES LANGUAGE C)
set_source_files_properties(filename.c PROPERTIES LANGUAGE CXX)
Where the FILES_SRC variable holds all my source files.
I am using CMake 2.8.12 and the Visual Studio 11 ARM generator.
Any idea how I could fix this?
I ended up compiling the library using the C compiler and added the C++ code in a separate library for which I created a C interface so it can be called from my C library.
Related
I am a question about dll use in linux. I have dll and .h file that work good in windows. But now I need to work this program in linux. If I write a .cpp file that
function call the dll file's function. Could I compiler this .cpp file to assembly or to .so file. Then I can use .so file without original dll file ?
If you have a DLL that builds on Windows, then provided the C++ code is portable, it should be possible to compile the same code on Linux to produce a shared library (.so file), which is Linux's equivalent to Windows DLLs. There is good background on this topic here.
If your source code (i.e. CPP or header files) uses #include for headers that are Windows-specific, you will have to make that code portable in order for Linux to build and run it. One approach is to just try compiling your code on Linux and see what errors arise. If you want to be more proactive, for C++ portability guidelines see here.
I'm trying to port our project from autotools to CMake and got stuck on fortran compiler settings. The project consists of C++, Fortran and Fortran90 pieces. In our autoconf/automake project we have simply defined FC and F77 together with corresponding flags like FCFLAGS and FFLAGS. But in CMake it seems to work a bit differently.
What I did so far:
project (blah-proj CXX Fortran)
... in ibm case ....
set (CMAKE_Fortran_FLAGS "-qfullpath -qinitauto -qnolm -qinit=f90ptr -qfree=f90 " )
and in the source directory CMakeLists.txt:
file (GLOB_RECURSE libblah_f_sources *.f90 *.f)
add_library (blah_f ${libblah_f_sources})
set_target_properties (blah_f PROPERTIES LINKER_LANGUAGE Fortran)
With gfortran on linux it works fine as it's only one binary, but on AIX there are 2 different compilers called xlf and xlf90. Of course it doesn't work as CMake tries to compile both *.f and *.f90 files with same compiler.
It doesn't seem I got what I really wanted, but at least it solved the problem at the first approximation. I kept same structure but then I let compiler itself decide what kind of file it is. Of course I had to remove the version-dependent directives like -qfree=f90 or -qfixed=128 in the hope that compiler is smart enough to guess them from the file extension.
I've got a project which is going to be a c++ library for use in other c++ code.
It's made of a single .cpp implementation file and a single .h file for the interface. Normally I'd just compile the .cpp implementation file and then link it with other files with g++ in something like Ubuntu, however in Xcode 5 there's the Option Product>Build, Product>Build for... Running,testing, profiling and then there are the Perform action options to compile analyse, pre-process and assemble individual files. So with Xcode 5 how exactly do I complete my c++ library project in that I can then include it in other programs? And what happens when I use the options mentioned above like build and compile, because I see no new output files even though the build is successful - I'm guessing they go somewhere else I don't know about. I've googled this but I mostly find Xcode 4 stuff.
Thanks,
Ben.
I am trying to use GLM to load a .obj object in my Objective-C Program (Xcode 4.4 Mac Os X). I have added the glm folder to my project. i try to import it using #import "glm/glm.hpp", but the program doesn't build. some of the errors are the following: (this errors are produced in the GLM files)
namespace glm{ //Unknown type name 'namespace'
namespace detail
{ .....
It doesn't find the cstdlib, cmath, and other libraries.
This happens because my program is in Objective-c and the GLM doesn't work with this language?
Those are all symptoms of trying to compile a C++ application with a C compiler. Namespace is a C++ keyword, and cstdlib, cmath, etc. are C++ names for standard C headers. You'll have to migrate your project to Objective-C++ to be able to use GLM.
Any files that uses the GLM library will require that file extensions to be renamed to .mm as it uses Objective-C++. Also, as it is only a file, and not a framework, you only need to put #import "glm.hpp"
I have a DLL that I am trying to link with a libjpeg LIB using MSVC 2008 that is generating Unresolved External Symbol errors for the libjpeg functions. I also have a test project that links with the exact same libjpeg library file and links without error and runs fine too.
I have triple-checked my LIB path and dependent LIBS list settings and literally copy and pasted them from the EXE project to the DLL project. I still get the errors. I do have the libjpeg include headers surrounded by extern "C" so it is not a name mangling issue and the unresolved external warnings show the "missing" libjpeg functions as undecorated (just a leading underscore and the # sign parameter byte count suffix after each name).
What could make the linker with the DLL project be unable to find the functions properly when the test EXE project has no trouble at all? I'm using the pre-compiled 32-bit static multi-threaded debug library which I downloaded from ClanLib.
Thanks,
Robert
After a lot of experimentation I found the solution. It turns out the problem was due to a difference in the calling convention used by the DLL and the LIB projects (In MSVC 2008 this is set on the Project Properties, "Configuration Properties -> C/C++ -> Advanced" setting. The DLL project was set to __stdcall and the LIB was __cdecl. Recompiling LIBJPEG with __stdcall fixed the problem.