Over the last few days I've been tinkering with mod_pLua on Windows (https://sourceforge.net/projects/modplua/ or https://github.com/Humbedooh/mod_pLua).
The pre-built Windows binary works a treat, except it doesn't seem to have been compiled with mod_dbd support for database connectivity. The documentation suggests that to enable this feature you must compile with a certain tag, so I've been trying to compile the module in VS2010 - hoping that I'll be able to get mod_dbd support working at some point - but I've run in to a snag. It just will not compile.
What I've done so far:
Included apache/include and apache/lib, which got rid of a lot of
errors
Included lauxlib.h, lua.h, luaconf.h and lualib.h from Lua 5.2, which got rid of a lot of errors
Compiled a .lib file from Lua 5.2 sources and included it, which fixed a few errors
The errors I'm getting at the moment are:
error LNK2019: unresolved external symbol _luaL_openlib referenced in function _lua_dbopen C:\Users\Michael\Desktop\Projects\C\mod_plua\mod_plua.obj
And a plethora like this:
IntelliSense: a value of type "const char ()(cmd_parms *cmd, void *cfg, const char *arg)" cannot be used to initialize an entity of type "cmd_func" c:\users\michael\desktop\projects\c\mod_plua\mod_plua.h 394 5
As I'm not a C/C++ native, I only have a vague idea of what's wrong, and have likely done something wrong in my attempts to fix the issue. If someone could guide me in the right direction (or better yet, write a little instructional on how to compile the module from start to finish) I would be so happy.
I've uploaded my VS2010 project files and source here: https://dl.dropboxusercontent.com/u/51243175/mod_plua_vs2010.7z
Self-answer:
The primary reason for the failure to compile was the Lua .lib file. The Microsoft compiler does strange things when dealing with C code, so I got an appropriately compiled version of the .lib from the LuaBinaries SourceForge repository (http://sourceforge.net/projects/luabinaries/) - specifically, 5.2.3/Windows Libraries/Dynamic/lua-5.2.3_Win32_dll10_lib.zip (which is compiled for VS2010).
This didn't enable mod_dbd support, which requires headers and sources from the Apache APR project, but it did allow successful compilation.
You should not be using mod_pLua really, I haven't worked on that for nearly 3 years ;) You should use mod_lua instead, which comes bundled with httpd and works pretty much the same way (although it does not support the php-like scripting that mod_pLua does)
For DBD specific setups (especially how to use it on Windows), see http://modlua.org/api/database
Related
I want to use some avx2 functions by including <immintrin.h> library in my project; however, Vscode does not seem to recognize these functions, as it is showing that my project contains various identifier "__m256i" is undefined errors as the attached pictures. I can compile and run smoothly, but the errors are really disturbing. I tried adding the declarations of these types into the Vscode path, but it does not help.
I am using the latest Vscode version in Centos 7.7.
Vscode show errors
Try added the include path, but does not help
__mm256i is a typo for __m256i.
The type names have 2 underscores and one m like __m128i
The intrinsic function names have one underscore and 2 ems like like _mm_add_epi32
I can compile and run smoothly, but the errors are really disturbing.
That's highly implausible, are you sure you're not running an old version of your executable from before you introduced this bug in your source? This is an error, not a warning; gcc won't produce a .o from a source file with this bug. Hard errors are the opposite of compiling "smoothly".
I solved the problem myself by restarting my computer. I think somehow at that time the computer did not recognize the definition of Intel AVX functions.
I have one windows project built in VS 2015 in windows7. Now I have to use one third party library (implemented in C) built in Mingw - 64 bit (for windows). When I try to link this library I am getting one compilation error :--
Unresolved external symbol __chkstk_ms.
Now I have resolved this issue by linking 2 more libs - libgcc.a and libssp.a.
But after, that when I run my application, I have started getting memory exception in some routines which was working fine previously.
I have doubt I should not solve this compilation error by using these 2 libraries (as these are not windows). Instead of it, there should be some windows / VC run time library which should be providing implementation of this routine.
Can someone please suggest right way to resolve this linking error.
A windows application I've been working on, is due to delivred without the use of CRT.
There's a few good articles descirbing the guidlines and benefits of doing so (none of which I could find upon writing this question - sorry) . Other then not using CRT symbols explicitly, it's all about linker and compailer configuration. My Release and Debug configurations are nearly identical now , and both specify /NODEFAULTLIB:"LIBCMT" only diffrence is the Run time flag /MT (in Release) vs. /MTd (in Debug) - that is required as I'm using __try/__except syntax for SEH, and so the only needed function is _except_handler3(). However, the Debug version is beeing built successfully, and the Release version fail with Unresolved Symbol _except_handler3 linkage error. When forcing Release version to compile with /MTd - this issue is solved.
How is that possible? which .lib contains the _except_handler3 export? and how can I solve this?
For an application without CRT see: http://blog.kalmbach-software.de/2008/02/02/smallest-application-size-for-win32-console-application/
But if you want to use __try / __except you need to use the CRT; or you need to write your own "_except_handler3".
See also: _except_handler3
Also you have the CRT source, and you can take a look into the source, to see what it is doing!
See: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src
I'm having a strange problem with include files and an apparent disconnect between Eclipse's build process and its error reporting. I'll give detailed steps to reproducing this problem, so we can narrow the causes down as quickly as possible.
Eclipse 3.7.1 (Indigo SR1) for C/C++ Linux Developers, Ubuntu 10.10 64-bits
It all started when I imported an existing project that "makes" just fine on its own: I thought Eclipse would help considerably in navigating the files and figuring out what does what. However, some of the #included system headers seemed not to be having the correct effect in Eclipse's view. This was very puzzling, and in the course of investigating this, I managed to recreate the problem in a tiny sand box.
Step one: Create a new C project (File: New: C Project) using the Hello World ANSI C Project sample. The parameters are Executable: Hello World ANSI C Project/Linux GCC, the remaining Empty projects set to Linux GCC, and GNU Autotools set to Hello World ANSI C Autotools Project. Call it "hello". Be sure to generate the makefile automatically (Advanced Settings, I believe it is the default).
Step two: Adjust the include path. Using Project: Properties: C/C++ General: Paths and Symbols: Includes: GNU C, set the search path to /usr/local/include, /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include, /usr/include. The second path depends on the exact version of gcc you have installed. This doesn't matter too much, as long as the build path includes at least /usr/include.
Now if you open hello.c, it looks very simple, and Eclipse is quite happy except for return EXIT_SUCCESS;, which cannot resolve EXIT_SUCCESS. Replace EXIT_SUCCESS with a zero (0) and Eclipse gives the all-clear. Select Project: Build Project to generate the executable.
Open a command-line window and drill down to your Eclipse workspace folder's hello/Debug subfolder. Once there, you can run the executable with the line ./hello.
Now the fun begins. Modify hello.c to read in its latter part:
#include <fcntl.h>
int main(void) {
printf("Hello World!\n");
int zz = SPLICE_F_MOVE;
printf("zz (SPLICE_F_MOVE) is '%d'\n", zz);
printf("Bye World!\n");
return 0;
}
You'll get an error on the int zz... line: "Symbol 'SPLICE_F_MOVE' could not be resolved". If you Build the project, you'll get a similar error in the console view: "error: 'SPLICE_F_MOVE' undeclared".
Now if you change the preamble to:
#define _GNU_SOURCE
#include <fcntl.h>
You still get the error on the int zz line (in the editor), but the project will Build correctly! You can confirm this by running the binary in the command-line window you opened earlier. This is really odd since examination of /usr/include/fcntl.h will show that it #includes <bits/fcntl.h>, and that latter header #defines SPLICE_F_MOVE (and a bunch of others) in a block guarded by #ifdef __USE_GNU (__USE_GNU gets #defined if _GNU_SOURCE is #defined). Why on Earth isn't our #define _GNU_SOURCE properly propagated in the workspace perspective?
So this is my problem in a nutshell: why is it the editor (and all of Eclipse CDT) reports an error (apparently by refusing to process correctly an include), but that the underlying build succeeds?
I had similar problems working with GNU and non-GNU compliant toolchains for cross-compiling various microcontrollers. CDT reports lots of errors, but the actual build works perfectly, even when all the header includes are correctly located in the project settings.
The problem is in how CDT operates as distinct from your make system build. CDT is a standalone lexer, parser, and preprocessor and doesn't make use of the toolchain you're using to do the build. This normally would work fine once you set the project settings to match those generated as command-line arguments to your build tools, but many toolchains frequently include hidden implicit defines as part of their compiler/preprocessor itself. The documentation for the implict/hidden defines is usually sketchy and incomplete in my experience, making it nearly impossible to determine which defines are set for a given toolchain (sometimes even dependent on build options) and what they mean. While it may look like you have all the correct defines set to reach the one you're having a problem with, I usually find (especially with GNU) that there are some you're missing that prevent the switch from being processed the way you expected.
When I debug something like this, I first make sure any headers in my project directory are found first if they have names matching those in other directories, then I slowly start moving headers from the standard include folder to my project folder. CDT doesn't do a very good job of indicating which possible versions of a header file it's parsing first, and it frequently pulls system environment settings when you least expect it, but it does look in your project folder for headers first (if you haven't set the system headers path in your project settings to take precedence). By moving the system headers from the location you're looking at to your project directory, you know for sure exactly which header file is being parsed by CDT. Furthermore, if you rebuild your index after doing the move, then open the file in Eclipse, CDT will indicate what switches it believes are enabled or disabled by greying-out or folding the branches not enabled in the header. Following this process has solved this exact problem for me every time, revealing when I had paths to multiple copies of the same header, accidentally duplicated headers, had defines or includes under unexpected switches, etc.
I have the same issue, but didn't even do anything that complicated to produce it--I just made a hello world project of the type you describe and get the same error. Note that, however, in my case, it may be due to a borked install of cygwin--for instance, I had other errors concerning failing to include the .h files, and a complete deletion/reinstall of cygwin removed those errors but the 'Symbol ... Could not be resolved' error remains.
I then decided to make a second such project, and they both report such an error in the 'problems' view, but only one of the projects actually shows the error underlined etc. in the editor (!)
Maybe this issue comes from Ijndigo itself. Did you tried the same with the latest Indigo SR2? I opened a number of bugs for Indigo and its SR1 in eclipse bugzilla.
I know a question like this was already asked, but the situation is a little different, and all the answers on that problem didn't work for me.
I'm trying to compile some C code in VS2008 and it doesn't create an exe. Also, when I try to run it with f5, I get:
This application has failed to start
because MSVCR90.DLL was not found.
I did some googling and it said that this was because my c++ redistributable package wasnt installed. So I installed that, restarted everything and tried again. But alas, I still get the same error. Does anyone have any clue how to fix this?
It sounds like either a problem with your VS2008 installation, or something wrong with your DLL search path. MSVCR90.DLL is installed when you install VS2008, you shouldn't have to install any additional redistributable packages.
First I would check your PATH environment variable and make sure there is no gobbledydook in it that will break some of the entries, and if you don't find a problem there, then I would uninstall and reinstall Visual Studio.
You could also try searching for MSVCR90.DLL (and other DLLs like it), and move them to your Windows/System32 folder.
If you just want to get going now, another thing you could do is change your project to statically link to the runtime libraries, and then it wont even try to load that DLL. Go to your Project settings, Configuration Properties->C/C++->Code Generation and change Runtime Library from Multi-Threaded DLL to just Multi-Threaded (or any of the options that doesn't end with DLL).
Here are some things to check for your configuration of the project- under the general tab:
.1 Configuration type - exe in your case.
.2 Use of MFC: if this is an MFC application it might be more portable if you do: Use MFC in a static library.
.3 Use of ATL - if not using atl (or not sure) say Not using ATL.
.4 Under C/C++ -> Runtime Library: Say Multi-threaded Debug (for debug version) or Multi-Threaded (for release version).
If you are getting specific linker errors that say something is already defined:
This means that you have some parts of your app (separate libs being linked to your exe) that are built with different runtime linking:
You can:
Make sure that these libraries were compiled with the same version of visual studio as your application.
Change those projects to use static runtime: C/C++ -> Code Generation -> Runtime LIbrary: /MT or MTd (same as #4 above)
If you still have some specific errors try telling the linker to ignore certain libraries: Go to Linker->Ignore Specific Library and put in the library that you want to ignore. This is most common for 'libcmt.lib' or 'libcmtd.lib'. It is important also to know that lib ending with 'd' is usually the debug version. If you are creating a release build and you are getting 'already defined in libcmtd.lib' that means that somewhere you are linking a release lib to a debug lib.
if you delete the manifest file associated with you .exe, you will get the same error.
MSVCR90.dll is not installed in system32, but in the side-by-side folder, hence the manifest is required.
I have just been bitten by this and this page got me working again.
The key is to ignore MSVCRT and MSVCR90 libraries for the debug configuration. Set your linker -> Input -> Ignore Specific Library setting to include the following:
MSVCRT
MSVCR90
it is supposedly in the http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&displaylang=en visual studio 2008 runtime library. Yes! After installing that, openoffice update works.
If you give the finished exe to someone else they will need to install the latest visual c runtime to run it. This will only work for release build AFAIK. Visual studio should install the required runtime both release and debug into your path. The project probably has an additional dependency accidently set for an incorrect version of the runtime.
See if this page helps.
Go to your Project settings, Configuration Properties->C/C++->Code Generation and change Runtime Library from Multi-Threaded DLL to Multi-Threaded and then try to compile but it won't. Then change it to Multi-Threaded Debug and try to compile ,but it won't again and then you change it back to Multi-Threaded DLL and then it should compile and run.