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.
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.
Here is my setup:
Windows 7 x64, MingW, Msys, CMake, Freescale Kinetis SDK, Code::Blocks
I'm trying to get the project settings established by CMake into a proper Code::Blocks project. When I modify the provided build_debug.bat file with -G "CodeBlocks - Unix Makefiles", it indeed produces a .cbp file, as well as the normal Makefile (and it builds the project). However when I open this .cbp file in Code::Blocks, it basically just points to the Makefile, and building the project just runs make on the Makefile.
If I deselect "This is a custom Makefile" from Project Options, and add a source file to the project tree like a normal IDE, it doesn't get built correctly, ie the include files, libraries, linker stuff, compile options, etc., are not imported into the project itself. It seems the project is basically just a holder for the Makefile, so there is not much benefit to this as an IDE.
Of course if I add the source file to the original CMakeLists.txt which is part of the distribution, and rerun cmake (via the build_debug.bat file), then it works fine.
So is there any way to get a "real" IDE configuration out of CMake? I'm guessing the answer is No, since a "real" IDE configuration is a static thing, and a Makefile is a general (Turing complete) program, so there is no way in general to create this automatically, although I suspect for 99% of cases you're just specifying include directories, lib files, and compiler options, so no general programmability is truly needed.
I can probably try to figure out where the deeply obscured gcc calls are getting their include files from, what libs are being linked in, and what compile options are being used, and add all that stuff manually into a native Code::Blocks project, but this seems to defeat the purpose of having this already done for me by the package providers, and gets very tedious when building for a different CPU or development board.
Thanks
"Real configuration" is a CMakeLists.txt, and you need to modify CMakeLists when you editing project configuration. Both makefiles and IDE settings generated by CMake are temporary and you should not edit them.
Some IDEs are able to manage project configuration directly in the CMakeLists.txt
When it comes to using the terminal to build libraries manually and such I unfortunately do not have much experience and I'm stuck a bit here.
I've downloaded a library for objective-c which came with makefiles and such.
I can see that the folder also contains an executable file called "libtool", I did some searching and I suppose this is the program I have to use to build the neccessary .a files? Unfortunately I couldn't really find any useful article for this that seemed to work.
The folder for the library contains some .sh files, .pc files and also some .la files, but I'm a bit unsure of which ones I have to use as input to the libtool program to compile them into a .a file.
So my question is what files do you have to input into libtool to compile them into the necessary .a file? And what commands do you use exactly to accomplish this?
Thank you all for your time :)
First a little introduction to static libraries:
Static libraries in Unix environments (like Mac OSX, and Linux too) are actually just an archive of object files created by the ar command line program.
That is what the .a extension stands for: Archive.
To create a static library with some object files you can use the command like this:
ar crv libmy_library.a objectfile1.o objectfile2.o
As for your actual question, libtool should be called automatically from the makefile, creating the library, which is the file ending in .la. However, this is not the real library, the real library is in a hidden directory. You can find it by doing e.g.
find . -name '*.a'
But like I said, the makefile should already take care of everything, including installing the correct library in the correct place when you do e.g. make install.
For information about libtool, see this site.
I'm currently busy on a project where I need to use an external accessory to read Mifare 1k tags.
The accessory was provided with an SDK, written in (Objective ?)C++ and I followed the instructions provided to set XCode to "Compile sources as: Objective-C++" and added "-Obj-C++" in "Other linkers flags.
The SDK compiles fine then, but trouble is I am already using several libraries in the project (such as ASIHTTPRequest, JSONKit, ...) and I get compilation problems because of those new settings in those libraries. If I switch back to the previous settings, I get compilation problems in the reader's SDK
The question is: is there a way to compile only the class from the SDK as C++ and the rest of the project as objective-c ?
Edit: the SDK files consists only of .h (and a linked library)
thanks for your help,
Mike
Select the file you want to compile as Objective C++ from the file navigator, and then select the File Type in the file inspector view. This is in Xcode 4, but there is a similar mechanism in Xcode 3.
Try renaming the files where you are including the library headers to myClass.h for interface and myClass.mm for implementation files. This forces the files to be compiled as objective-c++.
I have resolved this problem:
You should set "According to file type" to "Complile Sources As",
Set "-ObjC++" to the "Other Linker Flags"
The last,you should modify the files's suffix to .mm that reference
the library method
well, in Build phases tab, there is a section Compile sources. For file you want to use Objective-C++ compiler add flag: -xobjective-c++
tested in Xcode 12.5
I got a .h file, two .lib files, a .dll file and a tiny test project from a hardware vendor to talk to their hardware.
Compiling and running their test project works just fine. Noteworthy: they don't use the .dll. I can throw the dll-directory and all of it's content away, everything works just fine.
To start things off I simply copied the communication parts of their code (connect, disconnect and send a command) into my project. This is actually all that you can do. I have included the .h file and pointed to the directory containing the .lib files. Just like in the tiny test project. It all compiles, but when I try to run the project complains that it is missing the .dll file.
Can anybody explain what is happening? How are libs and dlls supposed to work?
All of this is on windows, VS2005. I compared the .vcproj files and could not find any significant differences.
The test project is statically linked - the lib is included in the exe.
Your project is dynamically linked - the dll is referenced and therefore needed at runtime.
See this Stack Overflow question for more information.
Basically the answer depends on whether you are going to use static or dynamic linking for your executable.
With static linking, you need the .h and .lib files but not the .dll files to compile and link. Your executable will be larger but you won't need any of the .h/.lib/.dll files during runtime.
With dynamic linking, you just need the .h files to compile and link. Your executable will be smaller but you will need one or both of the .dll files during runtime.
For a more detailed treatment of this from the Visual Studio perspective, check out http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx -
"Dynamic linking differs from static linking in that it allows an executable module (either a .dll or .exe file) to include only the information needed at run time to locate the executable code for a DLL function. In static linking, the linker gets all of the referenced functions from the static link library and places it with your code into your executable."