I'm struggling with building NLua from source on Windows.
It requires a modified Lua version, otherwise my code fails with a missing "lua52.dll".
https://github.com/NLua/NLua/issues/53
I tried to get it from here
https://github.com/NLua/lua
then used "cmake ." and built the resulting "lua.sln" in visual studio.
What happens is that I get a "lua52d.dll" (note the "d"). If I rename it, a "System.BadImageFormatException" is thrown by "KeraLua" (when I try with some "NLua.exe" executable I found in the "tests" folder of NLua).
Can anybody tell me how to build the modified lua52.dll required by NLua?
I already have a binary that works but need to be able to rebuild everything by myself. Possibly I'm simply using the wrong source tree.
You're using the right source tree, its just that you're compiling the debug version of the dll, not the release version of the dll. The added 'd' is to denote that it is the debug version of the dll, not the release version.
Related
I'm trying to compile the SvnQuery project (https://github.com/kalyptorisk/svnquery.git) with the a version SharpSVN.dll which I created on my PC, but I keep seeing the error message CS0400: The type or namespace name 'SharpSvn' could not be found in the global namespace (are you missing an assembly reference?).
Using the SharpSVN.dll which comes with the SvnQuery source code, I do not see this error message, nor any other.
Both SharpSVN.dll files look the same when I open them in .NET Reflector, but there is one difference - the file which I created doesn't have version information. (To be exact: When you look at the file's properties in File Explorer, "File version" and "Product version" are empty.)
I followed these steps to create SharpSVN.dll:
Check out from https://ctf.open.collab.net/svn/repos/sharpsvn (tried trunk and the 1.1200x branch). Open VisualStudio command prompt (tried 2012, 2015 and 2017), cd to 'imports' folder, run 'nant build'. Result: no errors, but this doesn't create SharpSVN.dll (and I guess it shouldn't).
Now double-click SharpSvn.sln in the src folder. This opens VS2017. Compile Release|x86. Result: no errors, many warnings, SharpSVN.dll (with no version information) created in src\SharpSvn\bin\Win32\Release.
Any ideas about this issue?
Thanks...
I found the solution. My problem has nothing to do with the missing version number. In fact, I had compiled SharpSVN for a .NET version higher than that of the SvnQuery project. After increasing the .NET version number for SvnQuery and related projects, all compiled well. And SvnIndex.exe seems to run smoothly (test still ongoing).
I'm new to C++ and Allegro 5 but have been able to follow tutorials online and am able to build and compile several smaller projects successfully.
I cannot however get the demo project named Cosmic Protector to run and would like to at least learn what is wrong.
Unfortunately, I can't give you much to go on.
A window opens briefly and then closes, leaving the console open with the message..
process 6400 exited with code 255
If you have this demo running in VC 2017 with the latest release of Allegro 5 (5.2.4) installed via Nuget, I'd like to know that even.
The source for this program is available at...
https://github.com/liballeg/allegro5/tree/master/demos/cosmic_protector
Thank you, Jack
The allegro example programs and demos are usually built with CMake alongside the Allegro library. I just tested the CMake build of Allegro 5 with VS2017 on Windows 10 and it builds the Cosmic Protector demo successfully. You have to move the allegro dlls into the same directory as the exe, but other than that it runs perfectly.
As to why it's not working for you, cosmic protector depends on a data directory that holds it's resources. The working directory may be wrong, which would cause it to be unable to find resources. The data dir needs to be copied alongside the executable.
You can set the working directory to $(OutDir) under Debugging in Project->Properties and then it should find any data in the same directory as the exe.
How are you building cosmic protector?
Thanks to BugSquasher, I now have this working.
Here's how...
Start Visual Studio 2017
Create New Project of type Windows Console Application.
Name project CosmicProtector and save it in appropriate place on my HDD.
Disable precompiled headers and delete the any .h and .cpp
files associated with the new project regarding precompiled headers.
(for example pch.h)
Install Allegro 5.2.4 via Nuget.
In Visual Studio, navigate to Project Settings/Properties and ensure all
Allegro addons are enabled.
Copy the Cosmic Protector SRC and Header files and paste them into my
project directory.
Next in Visual Studio Project, Add the Source and Header files
respectively.
Rather stupidly, the step I had missed and that your reply brought my attention to was...
Copy the data directory and paste this into my project directory in the
applicable location.
Now build...
The project built right away, except for some errors reported in Game.cpp, GUI.cpp and Render.cpp
One error in Game.cpp, this being an instance of...
error C4996 'snprintf': This function or variable may be unsafe. Consider using snprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of snprintf to sprintf_s.
Three errors in GUI.cpp, were instances of...
Error C4996 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address all of these I changed each instance of strcpy to strcpy_s.
And one error in GUI.cpp, this being an instance of...
error C4996 'snprintf': This function or variable may be unsafe. Consider using snprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of snprintf to sprintf_s.
One error in Render.cpp, this being an instance of...
error C4996 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of sprintf to sprintf_s.
Then build and it works:)
Thank you so much for your reply as I had moved on to other things but will find it very useful I think being able to build and run this demo.
It's only your reply that has brought me back to it and this time, I am successful:)
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I am trying to figure out how to package an unchanged fork of VS Code.
My first steps were to follow the electron application distubution documentation, which has not been successful. I also found this post, where another user had the same question. However, the vscode-win32 gulp task seems to have been replaced by x64 and ia32 versions, and when I try running these tasks they generate an out-vscode folder as opposed to a full electron project.
This led me to believe that I can use this new out folder (as well as node modules, packages.json, etc.) with the electron release being used by VS Code to mimic the resources/app folder from the installed version of VS Code in Program Files, however when I try running electron.exe using this method I get:
The factory method of "vs/code/electron-main/main" has thrown an exception TypeError: Path must be a string. Received undefined
In short, I have been struggling with this for a couple of days, and I am out of ideas. If anyone has packaged the project and can offer a suggestion for how to do so, I would really appreciate it.
SOLVED
The issue seemed to be due to being branched off of master as opposed to release. I'd assume there are changes in main that aren't accounted for in the gulp task.
For anyone confused by my post, the expected behavior for a successful build is for a folder named VSCode-win32-x64 to be generated in the directory where your vscode clone is located.
Where do I get gtk-win32-3.0.lib from?
I am trying to use GTK3 with Code::Blocks. The thing is initially when I was trying to create a GTK project, it gave me an error that it can't find gtk.h. I then edited the wizard script and changed gtk-2.0 to gtk-3.0 as seen in an answer on Stack Overflow.
After doing that, it gave me an error cannot find gtk-win32-2.0. I changed this to gtk-win32-3.0 in the script but the error still persists.
I have both the files gtk.h and gtk-win32-3.0 in the GTK directory. I crosschecked this many times. Can someone help me with this?
I just discovered that I don't have a file 'gtk-win32-3.0.lib` in the gtk\lib directory. I manually created one in the directory and now Code::Blocks lets me create a project. I still don't know what should be present inside the library file.
Edit:
The project gets created after I added a blank file named gtk-win32-3.0.lib in the expected directory but the files doesn't get compiled.
Current error:error: ld returned 1 exit status
Didn't get more details regarding the error.
The same program gets compiled when used outside the project as an individual source file.
I just noticed I still have code::blocks installed (version 13.12). Note that I am on Linux. I just clicked on File|New|Project.
I then selected the new project to be a Gtk project, and most everything was ready.
You'll have to fill in a project name (Test99 in the screenshot) and a location.
I suspect you do need to have the gcc compiler installed, and of course the Gtk libraries. You'll also need pkg-config, which is necessary for configuration.
By default, the new project was configured to be a gtk-2 project. But you can change that by changing the part of the includes. Right click on the project name in the left panel (Test99), and select Properties. In Properties, select Project Build Options (don't be tempted to select Options instead of Properties in the previous step. I don't know why, but they're different!)
Select Linker Options, and you should see pkg-config gtk+-2.0 --libs with 'back-ticks' around it. Changing 2.0 into 3.0 should link with the libraries.
Go to Compiler Settings, then Other Options and again, you will find a similar entry pkg-config gtk+-2.0 --cflags (also with backticks). This detects where the gtk.h file lives. (Also change 2.0 to 3.0)
That should be it. This may not be the latest version of code::blocks. If you encounter problems, yell!