I just built an updated version of SDL.dll, an open-source C DLL that my Delphi project uses, with the Express edition of Visual C++ 2005. I dropped it in the folder with my EXE and tried to run it, but it won't load:
The procedure entry point SDL_RWFromFP could not be located in the dynamic
link library SDL.dll.
Now C never was my strong point, but I remember enough of it from college to try and track this one down. I went poking around in the source code to see what had happened to this function, and I found it grayed out, beneath a preprocessor directive:
#ifdef HAVE_STDIO_H
IIRC, STDIO is the standard C I/O library. I assume this means that it's not available. Anyone know why that would be and how to fix it? Is this a Visual C++ issue or an SDL one?
Most often in the Unix/Linux world, names like HAVE_STDIO_H indicate that the code has been 'autoconfiscated' (which is the official term used to describe the state of having been made to work with the 'autotools' such as 'autoconf'). In such a set up, the configure process would determine whether <stdio.h> was available and would set #define HAVE_STDIO_H 1 in the config.h file that it generates. The compilation would then discover that the platform has <stdio.h> and would compile the matching code (the stuff that is currently greyed out).
Adapting to your Windows environment, somewhat less than 100% confidently since there could be some other significance to HAVE_STDIO_H on Windows, you might decide that it would be OK to include -DHAVE_STDIO_H in the command line options when you run the compiler. Or you might create the config file by hand, and define -DHAVE_CONFIG_H (which is the normal way to indicate that configuration settings are in the file 'config.h'). In the 'config.h' file, you'd have #define HAVE_STDIO_H 1 as mentioned above.
Note: on Unix, you normally find a shell script called 'configure' which you run to create the config.h file. If you have Cygwin, there's an outside chance that you can use that script on Windows - I've just checked that an autoconfiscated package I created on Solaris was configurable on Windows under Cygwin and it mostly worked - all except some network handling. I'd not guarantee that it will always fail (but it's software - guaranteeing anything is pretty dangerous). I should add that the problem is in my auto-configuration code (the tests for the network functionality clearly aren't quite correct), and not in Cygwin per se. If I'd done the job properly, it would have worked. (Someone said "There is no portable code; there is only code that has been ported". That applies here.)
You do need a good simulation of a Unix environment. MingW might also work.
What do the preprocessor directives above it do?
Most likely, this is simply for determining some properties of your compiler, and it's greyed out because whatever the macro signifies, does not apply to your compiler.
Your problem is most likely elsewhere.
Since it can't find the function SDL_RWFromFP, you should probably see if that function is for some reason disabled by a preprocessor directive as well.
However, my guess is that the function exists, but does not get marked as __declspec( dllexport )
Without that, it won't get exposed so programs loading the DLL can call it. Most likely you have to #define something to specify that you want to create a DLL, which will enable the necessary preprocessor magic to insert the dllexport part in front of the function.
Normally, you should not have to add any HAVE_STDIO_H: those are not meant to be public anyway (although sadly many projects pollute the public namespace with those).
I would guess you did not build SDL correctly - or that Visual studio 2005 is not well supported by SDL (I don't know much about SDL, so those are really wild guesses without much information). Is there any test suite for SDL, such as you can test the built dll ?
Related
I'm trying to build the OpenCL ICD Loader in mingw gcc - no problem to use mingw-w64 instead, it's just that mingw is what I have installed already. I don't use Visual Studio - I don't hate it, I know there's free versions, it's just not what I'm using.
The OpenCL ICD Loader doesn't build in mingw gcc. The main reason is because of lack of DirectX 10 and DirectX 11 support. But all the ICD Loader does is get a dispatch table (presumably from the OpenCL driver/whatever it loads) and provide functions that call through that dispatch table. Some minor changes to the conditional compilation in icd_dispatch.h and icd_dispatch.c can omit the relevant functions and remove the dependency (as already has to happen for Linux builds), and it actually looks like this may have been supported in the past - there's preprocessor symbols cl_khr_d3d10_sharing and cl_khr_d3d11_sharing already defined if relevant headers are included, they're just not being used to conditionally compile the relevant chunks of code.
So there's that and telling the code to omit DirectX10 and DirectX11 functionality in the first place (I just commented out a couple of header-file includes, though that's obviously not a real solution). But then there's one more problem...
The file icd_windows.c uses the Windows API function InitOnceExecuteOnce - MSDN docs here. mingw (and I think mingw-w64) doesn't support this function - the def file for Kernel32.dll lists it but neither the function nor the related identifiers INIT_ONCE, INIT_ONCE_STATIC_INIT and PINIT_ONCE are provided by header files.
The MSDN docs IMO don't explain this very well. It can't be essential (it didn't even exist before Vista) and it has something to do with safe initialization of DLLs, presumably in a multithreading context.
Unfortunately, if I don't really understand what it does, then I can't implement a workaround for its not being there.
Clearly this Windows API isn't specific to OpenCL, so presumably this is an issue that other people have run into for other projects. So is there a standard workaround for this?
Or failing that, can someone explain what is meant particularly by "synchronous one-time initialization"? Sorry if that's a dumb question, I don't have much experience of multithreaded, I'd have thought one-time initialization is just that, irrespective of synchronous vs. asynchronous - so long as a second thread can't re-enter the initialization, you don't want to initialize again, so there's nothing to do synchronously vs. asynchronously anyway.
Or does it mean that if another thread tries to call the initialization, it will wait for the already-running initialization to complete before it fails (or possibly succeeds without re-doing the initialization)?
I wasn't sure the opencl tag was appropriate, decided to include it because of the context, sorry if that was wrong.
I came across the same problem. You have to add following line at beginning of icd_windows.c, before all #includes:
#define _WIN32_WINNT 0x0600
This helps with missing InitOnceExecuteOnce declaration. I also had to modify CMakeLists.txt, replaced SHARED with STATIC in line 22 which is responsible for linking libOpenCL. I did this because linker complained about missing ld lib:
add_library (OpenCL STATIC ${OPENCL_ICD_LOADER_SOURCES})
After doing these two things I got libOpenCL.a in build subdir. Compilation continued and failed with some other error, but I ignored this. I took created lib and successfully used it to build simple OpenCL app which lists all available platforms, devices and their details.
I have a large code written in C, but I did not write all of it myself. I wish to create an overview of the call structure in the code for reference. That is: I wish to know what (non-standard) functions are called by the different functions in the code, and thus create a hierarchy or a tree of the different functions. Are there any free, Unix compatible programs (that means no Visual Studio, but a Vim plugin or such would be neat) that can do this, or will I have to write something that can do this myself?
Doxygen does that too, it has to be enabled though.
For an overview of available tools see
http://en.wikipedia.org/wiki/Call_graph
There is a Vim plugin C Call-Tree Explorer called CCTree
http://www.vim.org/scripts/script.php?script_id=2368
As you mentioned a Vim plug-in, check out http://sites.google.com/site/vimcctree/. It uses CScope to generate the tree, so you will need to first generate a CScope db of your source files.
Have a look at http://www.gson.org/egypt/ This uses GCC to process the code and extracts the interdependencies within the program from the AST it emits.
gprof will do that. It also generates an execution profile, but in doing so it creates a call tree.
I just downloaded SourceTrail (https://github.com/CoatiSoftware/Sourcetrail/releases) and it did what I wanted, which was pretty close to what I think you want.
(What I wanted was to find out what routines called the function I was considering changing, or needed to understand).
Note that it is no longer maintained, but it did exactly what I wanted. It runs under Windows and Linux, and made finding who calls a function pretty trivial (as well as following that function's call tree down as needed). If you care, it has a GUI (is a GUI? whatever).
It does the parsing itself, but it didn't take very long to run, perhaps about the same time or a little less than compiling the code.
But if you want text only, or don't want to use a gui, or don't want to have it scan the code, this isn't for you.
(Notes - in my case, I was hyper-focused on one or 2 functions, and didn't care what system functions were being called. I spent some time stubbing out all the include files that were needed (since I ran the parse on one machine (A Linux machine) that didn't have all the include files needed for the Windows program I was looking at, and then did the exploration on a different (Windows) machine. Which, I should mention, worked perfectly. I just copied the entire source tree from my Linux machine to my Windows machine (which included the Sourcetail project file), loaded Sourcetail and had it load the project - done.)
I have been trying to compile open source projects since past few months with no success. I just don't know how to go about the entire thing. Readings over the internet have not helped much.
Some come with ./Configure and a Makefile while others with only a Makefile. How to use them to generate executables (or they have some other purpose ).
My machine currently has:
Windows XP,
Mingw Compiler for C/C++,
Cygwin
Do I need any other software?
Thanks!
Edit:
Thanks for the response. Currently I am trying to compile "Null Httpd". It comes only with a makefile.
In my command line prompt I type
/directoryContainingMakeFile/mingw32-make Makefile
I get
"Nothing to be done for 'Makefile'"
:(? Am I doing it the right way?
./configure is the first thing to run, if it exists -- it checks if your system has the requirements for the project, and also allows you to set project specific settings or simply set the default values.
Next, the command make (though some projects require automake, or cmake, which are similar but more powerful utilities) takes those configurations and builds from the source code into the executable. Make isn't a compiler in itself though -- its simply used to specify how to build the project. Most projects in C use gcc, probably with many standard libraries to be linked in, in which case this should run on top of cygwin perfectly well. If it has other dependencies however, you are on your own for the most part (this gets complicated very quickly -- if this happens, its usually a less time-consuming effort to work in the OS the source was made to compile on).
After this, you should find the binaries you require in the same directory :)
When I link to the one under Release/ ,got a fatal error:
LINK : fatal error LNK1146: no argument specified with option '/machine:'
Then I tried to link to the .lib under Debug/ and this time it works.
But what can be different?
Usually, no optimization is done to debug assemblies, while release assemblies are optimized. Debug assemblies will also often contain cruft like source file line numbers.
This isn't actually a C question; it relates to the platforms used.
Frequently, a project/solution will be set up to create a version for debugging and one for release, and putting them in Debug/ and Release/ directories is a common way to distinguish. The debug version will typically compile fast and run slowly, and contain information to link the internal execution to the source code (such as line numbers and variable names). The release version is typically slower to compile and faster to run, and it's much more difficult to track what's going on inside.
Obviously, there have to be differences between the debug and release versions, if only the appropriate compiler flags. However, in the build systems I'm familiar with, it's possible to make arbitrary other changes, and sometimes this will cause a release-version-only bug, which is a pain. Alternately, if the C code doesn't specify the behavior properly, the debug and release versions might interpret it differently, and that's also a pain.
In this case, I'd guess that there was a difference in how they were built. I can't really comment further without more information.
What is the OS? What is the C compiler used? What build system do you use (if you're using an IDE, possibly the one standard with the IDE)? What is the library you're using. Does your organization build it, or do you get it from outside? Knowing these things would give us a clue as to where to start looking.
You may want to change the build configuration for debug and release versions seperately.
I have a C code created in Plato3. I want to create an exe file so I can share it with others.
Can someone please tell me how is this possible ?
I have tried sending the exe file that is created when normally compiled, but it crashes every time in runs on computers other than mine ...
Please help,
Thanks :)
[EDIT]
Program running on windows xp or vista .. same error :
Compiler used : SilverFrost (Fortran/C/C++) Development Studio (Plato3)
This application has failed to start
because salflibc.dll was not found,
reinstalling the application may fix
this problem
salflibc.dll is a library installed by the compiler on your development machine.
salf = Salford C Compiler, the obscure compiler included in Silverfrost
libc = C-language runtime support library, necessary for the basic functionality of any program
.dll = dynamically-linked library, i.e. a separate file from your .exe file
You might look for a compiler option that looks like "statically link runtime library;" this might eliminate the DLL dependency. However, if the compiler were capable of doing that, one would expect it to be the default, if not the only way.
However, I recall from the olden days of Classic Mac OS that sometimes DLL runtime libraries were used, the benefit being upgradability. Sometimes is a key word, though. (I suppose when the compiler vendor is the OS vendor, as with MSVC or Apple GCC, it is the norm, though.)
Another trick from that environment was to put the DLL in question in the application's directory and distribute it with the app. Typically runtime DLLs are licensed for free redistribution.
At the very least you have to make sure that the executable is running on the same architecture/operating system that it was compiled on.
Additionally, you need to make sure that any third party, or system libraries that are needed are available on the other systems too.
update
Based on the new information and error message you provide, it looks like you need to re-distribute the salflibc.dll
I would agree with other commenter's and suggest a different platform for development that is more mainstream, or supported.