I have written a simple "do-nothing" OpenCL application (in C++ but using the C API) on Linux to get some data about OpenCL speed. It compiles fine and runs without error. I don't have a graphics card that supports OpenCL, but I need to test it on a GPU. I'm trying to build the application on my friend's Windows 7 64bit computer using the OpenCL implementation provided with NVIDIA'S CUDA Toolkit.
When I try to link to the OpenCL.lib file in CUDA\x64 I get undefined references for each OpenCL call within the program (using the standard C API). The same thing happens when I link to the OpenCL.dll in the system32 directory. If I link to the win32 library that came with the CUDA Toolkit, I don't get errors, but OpenCL cannot acquire a platform. All the undefined references I get when linking have an #20 or #46 or some random number on the end of the symbol name. I'm not familiar enough with Windows development to know how to fix this problem. What could be my problem?
I apoligize for any newbie-ness. Thanks for any answers!
I believe you'll want to use the library that doesn't give link errors.
The other errors you're getting are because you're linking mismatched code together.
Then focus on trying to determine what your platform identifier should be.
I think you were close but gave up too soon
Related
The question appeared when I was trying to install SFML (Simple and Fast Multimedia Library for c++) on codeblocks Mgw32 on my Thinkpad2 tablet. I did everything according to instructions from SFML web page. Then I copied and successfully compiled test code (simple code that creates window and draws circle) from the same instructions.
However code always was crashing during the run time (I was getting usual windows crash report saying that something went wrong in msvcrt.dll). I figured out that it crashed when sf::RenderWindow instance was created. All SMFL functions before sf::RenderWindow was working properly.
I checked web and read that some people managed to solve same problem (compiles but crashes during runtime) by compiling SFML by codeblocks on their computers. And here comes something that I want to understand: what is the difference between library that was downloaded already in compiled form for particular OS and particular coding environment that is used by user and library that was compiled by user? Does compilation by user adjust code for software and hardware that user uses? If so then to what extent and will (or rather how will) this compiled code run on different hardware with the same OS?
I feel that question is very broad (it's because I have very limited knowledge in the area) so I don't expect precise answer all that I want is just some hit that can point direction where I should look for answer.
Lots of questions out there on trying to get NVCC to use the intel compiler. It doesn't work, I get that.
The most common answer that people give is to compile the device code into a library using NVCC/cl.exe and then compile the host code separately and link them. I'm attempting this, but am getting nowhere.
In VS2012 I have created a solution with 2 projects - one CUDA, the other a console application.
I have set the CUDA project to compile with VS2012 into a static library. It compiles no problem.
I have set the console application to intel 14.0 and to compile as an exe. I have also added the correct path to "Additional Library Dependencies" and have told the compiler about the CUDA library through "Additional Dependencies" (where I also told it about cudart_static.lib).
Build dependency is also set to compile the CUDA project first.
However, this setup is no good. Gives me an error which even google is at a loss for:
Error 5 error MSB4057: The target "ComputeLegacyManifestEmbedding" does not exist in the project. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\Win32\PlatformToolsets\Intel C++ Compiler XE 14.0\Toolset.targets 1162 7 rxnCalc_cpp
To verify that the linking is ok, if I set both projects to compile via VS2012 I get no problems.
OS - Windows 7 64bit (32bit application though)
Platform - VS2012
Cuda Toolkit - 6.0
Cuda Compute Version - 5.0 (and compiled as such)
So, am I just wasting my time or is there something I'm missing? It seems I have gone through a hundred posts, but I have yet to see a single success. Lots of people anxious to tell you that this is what you should do, but no one to tell you how to do it!
For everyone out there using windows and trying to get CUDA and the intel compiler to co-operate, see my initial question on how I set up the solution.
To get it to work, as per Roger Dahl's suggestion, I changed the CUDA project to a DLL.
This involved the following modifications:
Change CUDA project to dll
Add __declspec(dllexport) to CUDA wrapper function
Point console linker to the DLL lib file
This works and I am now able to utilize all intel compiler optimizations.
However, please note, I did need to set the intel compiler to only do single file IPO. Multi file IPO will cause errors, this was somewhat expected.
Hope this helps others in the same boat.
Trying to compile a C++ kernel project with MinGW & NASM (formerly DJGPP & NASM). Have actually tried Cygwin too, with the exact same results below:
First, just swapped out \DJGPP\bin for \MinGW\bin. Got the following link error: target coff-go32 not found.
Swapped target to elf32-i386, and got cannot perform PE operations on non PE output file 'build/kernel.elf' This was a bit of a weird error, since to my knowledge I'm not doing any 'PE operations'.
Changed target again, to pe-i386, got a new error build/Common.o:Common.cc:(.text+0x2a): undefined reference to 'atexit'
It seems MinGW is generating atexit calls for static classes. DJGPP did not. The kernel does it's own DTOR handling during shutdown. I am aware that defining atexit would 'solve' this, but that would be more of a hack at this point, and not a longterm solution. I want rather to get MinGW compiling the existing code without any (or minimal) modifications.
Frankly, I'm not that familiar with the Windows build environment and could use any tips on what to do. The project (minus the changes listed above) compiles and boots fine under DJGPP. The difference seems to be in the way DJGGP and MinGW handle compile-time class declarations?
EDIT: Finally broke down and built a cross-compiler on Cygwin. All working now.
You need to build a free-standing cross compiler. This problem has been referenced many times at the OSDev Wiki to the point that most people recommend you begin writing a kernel by first creating a cross compiler.
This article will provide a step-by-step reference to building your own cross compiler. Note, in Windows, you may have to build the cross compiler using MingW or Cygwin
I've downloaded HD Photo Device Porting Kit 1.0 and successfully compiled and executed it on x86 PC.
I want to port the image viewer program to ARM-based Windows Mobile Smartphone, but there is some missing ARM code.
First, no "/image/x86/x86.h" equivalent header file for ARM. But the file is very simple, so I copied and renamed it to "arm.h" and successfully compiled and linked the source code.
But at runtime, DWORD alignment exception occurrs. I found that on ARM build, it seems that ARMOPT_BITIO should be declared for properly aligned read & write. But with ARMOPT_BITIO, some IO functions are missing, e. g. peekBits, getBits, flushToByte, flushBits.
I copied x86 version of these functions (peekBit16, flushBit16, etc), but no luck, it does not work (I've got a stack overflow error).
I can't debug the complex HD Photo source files. Please let me know where can I find the missing ARM code.
Any help would be much appreciated. Thanks!
Based on my experience of porting some Microsoft code to ARM Linux, I do not think there is an easy way around it, unless someone has ported it already. You'll have to dive into this sort of low-level debugging.
Bugs I encountered were mainly related to unaligned access, and missing platform API calls. Also incorrect preprocessor checks resulted in code thinking it's running on big-endian platform.
The method I found useful to debug in such scenario is to build the code for the target platform and for the platform where it's known to work, and debug/trace these builds in parallel using a number of use cases. This will catch the most severe bugs.
More out of interest than anything else, but can you compile a DirectX app under linux?
Obviously there's no official SDK, but I was thinking it might be possible with wine.
Presumably wine has an implementation of the DirectX interface in order to run games? Is it possible to link against that? (edit: This is called winelib)
Failing that, maybe a mingw cross compiler with the app running under wine.
Half answered my own question here, but wondered if anyone had heard of anything like this being done?
I've had some luck with this. I've managed to compile this simple Direct3D example.
I used winelib for this (wine-dev package on Ubuntu). Thanks to alastair for pointing me to winelib.
I modified the source slightly to convert the wchars to chars (1 on line 52, 2 on line 55, by removing the L before the string literals). There may be a way around this, but this got it up and running.
I then compiled the source with the following:
wineg++ -ld3d9 -ld3dx9 triangle.cpp
This generates an a.out.exe.so binary, as well as an a.out script to run it under wine.
If this is not about porting but creating, you should really consider OpenGL as this API is as powerful as DirectX and much easier to port to Mac or Linux.
I don't know your requirements so better mention it.
You can't link against wine as it's essentially a call interdictor/translator rather than a set of libraries you can hook into. If linux is important go OpenGL/SDL/OpenAL.
I believe(I've never tried this) you can can compile Linux binarys against winelib. So it works just like a Linux executable, but with the windows libraries.
http://www.winehq.org/site/docs/winelib-guide/index
go to the directory with the source and type in:
winemaker --lower-uppercase -icomdlg32 -ishell32 -ishlwapi -iuser32 -igdi32 -iadvapi32 -ld3d9 .
make
wine yourexecutable.exe.so
If you get this Error:
main.c:95:5: error: ‘struct IDirect3D9’ has no member named ‘CreateDevice’
make sure you have named your file main.cpp and not main.c.
There is currently no way to compile DirectX code to directly target Linux. You would build your application like you normally would, then run it using a compatibility layer like Wine/Cedega.
you can compile a directx apps in linux, but not launching it straight away.
if you use a crosscompilator that makes windows exe and point to the windows sdk and directx sdk.
Although this question is dated, I decided to updated on it, because it keeps popping up for me as the first suggestion for this particular problem.
As the previous answers already suggested you can compile against winelib. However, there are yet another two solutions.
The first solution would be either to use the MinGW provided for your distributions. MinGW is a 'cross-compiler', that compiles either from macOS or linux to windows and has support for DirectX. Note, that C++ libraries compiled with MinGW are not compatible with the MSVC compiler's ABI, thus cannot be consumed. However, the resulting binaries can be executed using Wine.
The second solution would be to use clang as a cross compiler. Clang usually includes the Compiler and Linker needed for Windows out of the box. However, it'll require you to include provide the headers and libraries yourself. On the other hand, libraries compiled this way are compatible with MSVC and, thus, can be consumed by it.
Side note:
Latter allows you to setup an CI server using linux (I did so on a raspberry pi), which creates compatible binaries for end users.
Wine is the only way to run DirectX in Linux