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.
Related
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 new to OpenCL. I have written a vector addition code in OpenCL with help from Internet. I have included one header file i.e. CL/cl.h using #include.
I am using NVIDIA graphic card and the OpenCL implementation is NVIDIA_GPU_Computing_SDK. My OpenCL header files are residing at this path /opt/NVIDIA_GPU_Computing_SDK/OpenCL/common/inc. I can run OpenCL programs through linux terminal by adding this path when compiling my code. But now I want to write CMake file for this code. CMake files are working fine for C programs, but not OpenCL programs because of this Path problem. In terminal, I used to enter $cmake ., after this $make, it will search for a Makefile which is created by cmake, now my error is after entering command make
fatal error: CL/cl.h: No such file or directory!
Now tell me how can I include this header file into CMake file?
You will need to put these lines into CMakeLists.txt:
include_directories(/opt/NVIDIA_GPU_Computing_SDK/OpenCL/common/inc)
link_directories(/opt/NVIDIA_GPU_Computing_SDK/OpenCL/common/<lib or something similar>)
add_executable(yourexe src1.c ...)
target_link_libraries(yourexe OpenCL)
But beware that this is not portable, because OpenCL SDK can be somewhere else on another machine. The proper way to do this is to use FindOpenCL.cmake module.
Maybe you can use a CMake "find" script like:
http://gitorious.org/findopencl/findopencl/blobs/master/FindOpenCL.cmake
http://code.google.com/p/opencl-book-samples/source/browse/trunk/cmake/FindOpenCL.cmake?r=14
CMake file example from OpenCL Programming Guide Book: http://code.google.com/p/opencl-book-samples/source/browse/trunk/CMakeLists.txt?r=14
I was looking for FindOpenCL.cmake macro which would work well on Windows, OSX and Linux... I couldn't find any which did work well on every platform, so I wrote new one which I use in couple of projects (webcl-validator and opencl-testsuite).
https://github.com/elhigu/cmake-findopencl
Especially Windows support is improved in this one.
In Windows it checks if 64bit or 32bit lib should be used and it also tries to find libraries from according to environment variables set by Nvidia, Intel and AMD OpenCL SDKs.
It also tries to find .lib in Cygwin, which didn't work with other scripts I tried.
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.
IDE: VS2005
Say I am using Poco library and the executable needs below dlls. I have to put them in same directory where the executable is.
msjava.dll
msvcp80.dll
msvcr80.dll
PocoFoundation.dll
PocoNet.dll
Is there any way that can build a dll-free executable? Thanks.
They don't have to be in the same directory. They can be in another directory if your PATH variables includes the directory they are in.
It looks like the Poco libraries can be downloaded as source, so you should be able to build them as static libraries and make a stand alone executable.
Update
For the msvc DLL's, you can build against static libraries. Bring up the properties of your project, go to C/C++, Code Generation and modify "Runtime Library". Make sure to choose a library other then "Multi-threaded DLL" or "Multi-threaded Debug DLL." You will also want to make sure you do that for the Poco libraries as well.
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."