I have the following trivial Lua program which I copied from the book Programming In Lua
#include <stdio.h>
#include <lua.h>
#include <lauxlib.h>
#include <lualib.h>
int main (void)
{
char buff[256];
int error;
lua_State *L = luaL_newstate(); /* opens Lua */
luaL_openlibs(L); /* opens the standard libraries */
while (fgets(buff, sizeof(buff), stdin) != NULL)
{
error = luaL_loadbuffer(L, buff, strlen(buff), "line") ||
lua_pcall(L, 0, 0, 0);
if (error)
{
fprintf(stderr, "%s", lua_tostring(L, -1));
lua_pop(L, 1); /* pop error message from the stack */
}
}
lua_close(L);
return 0;
}
my environment is cywin
my make file looks like this:
CC=gcc
INCLUDE='-I/home/xyz/c_drive/Program Files/Lua/5.1/include'
LINKFLAGS='-L/home/xyz/c_drive/Program Files/Lua/5.1/lib' -llua51
li.o:li.c
$(CC) $(INCLUDE) -c li.c
main:li.o
$(CC) -o main $(LINKFLAGS) li.o
clean:
rm *.o
rm main
My /home/xyz/c_drive/Program Files/Lua/5.1/lib directory contains lua5.1.dll lua5.1.lib lua51.dll and lua51.lib
Trying to build my main target I am getting the following errors:
li.o:li.c:(.text+0x35): undefined reference to `_luaL_newstate'
li.o:li.c:(.text+0x49): undefined reference to `_luaL_openlibs'
li.o:li.c:(.text+0xaf): undefined reference to `_luaL_loadbuffer'
li.o:li.c:(.text+0xd9): undefined reference to `_lua_pcall'
li.o:li.c:(.text+0x120): undefined reference to `_lua_tolstring'
li.o:li.c:(.text+0x154): undefined reference to `_lua_settop'
li.o:li.c:(.text+0x167): undefined reference to `_lua_close'
Any ideas about what I might be doing wrong here?
The problem is that you have named the libraries on the link command line before the object files that require them. The linker loads modules from left to right on the command line. At the point on the line where you name -llua51, no undefined symbols that could be satisfied by that library are known. Then you name li.o, which does have unknown symbols.
Some Unix-like environments don't treat this as an error because part of the link process is deferred to the program load when reference to .so files are satisfied. But Cygwin, MinGW, and Windows in general must treat this as an error because DLLs work quite differently from .so files.
The solution is to put -llua51 after all the .o files on your link line.
Edit: Incidentally, it appears you are linking against the Lua for Windows distribution, but building with GCC under Cygwin. You will want to use Dependency Walker to make sure that your program does not depend on the Cygwin runtime, and that it does depend on the same C runtime as the lua51.dll from Lua for Windows. IIRC, that will be the runtime for the previous version of Visual Studio. It is possible to make GCC link against that, but you will need to be using the MinGW port (which you can use from Cygwin), and link against a couple of specific libraries to get that version. I'm away from my usual PC, or I'd quote an exact link line. (I believe you need -lmoldname -lmsvcr80 or something like that, as the last items on the link line.)
It will cause mysterious and very hard to diagnose problems if more than one C runtime library is in use. The easy answer is to use the same one as your preferred Lua DLL. Another alternative is that the Lua Binaries project has pre-compiled Lua DLLs for a wide array of C toolchains on Windows. If you need a Lua application that understands the Cygwin environment, you will want one that is built by GCC for Cygwin and not the Lua for Windows flavor. Lua Binaries will be your friend, or you can build Lua your self from source.
The names in the Lua API do not have those leading underscores. Try compiling with -fno-leading-underscore.
Related
I'm having trouble getting started with Metal's shader compilation.
How to make a MTLLibrary that can link to a MTLDynamicLibrary (or MTLLinkedFunctions), in particular a library that declares extern functions that are to be resolved at runtime when providing preloadedLibraries (or linkedFunctions) in the compute pipeline descriptor? For example, I can compile the following to air using xcrun metal (with option -c), but then invoking xcrun metallib (even with option --split-module-without-linking) gives the error LLVM ERROR: Undefined symbol: _Z3addjj. In other words, how do I make a 'partially bound' metal library?
// shader.h
extern uint add(uint a, uint b);
/// shader.metal
#include "shader.h"
kernel void kernel_func(uint gid [[ thread_position_in_grid ]]) { add(gid,2); }
WWDC2021 mentions this extern technique, but the Dynamic Library Code Sample from the previous year doesn't use extern (or the installName), so I don't make sense of it.
When creating an executable library that uses a dynamic library, there are two points where you must include the dynamic library (I thought there was only one).
The process is different depending on whether the executable source is compiled at build or runtime. I'll describe for the case of runtime, because I haven't yet figured out the case for the executable library created from a metallib file.
The first point is when you compile the executable, where you must include the dynamic library in the libraries field of the CompileOptions. The library is there at this point just as a dummy, to check that you have a dynamic library that defines the declarations allowing for proper linkage, though that linkage doesn't occur at this stage, just the checking.
The second point is when you create the pipeline state, where you must include the dynamic library in the preloadedLibraries field of the pipeline descriptor. This time, the dynamic library is not a dummy but the real library you plan to use, as it will be linked with the executable during pipeline creation.
I know... Another one of this... But no one else's error is the same as mine and I've been trying to build opencv with mingw32 for days now.
When building OpenCV with mingw the command mingw32-make fails at some point trying to compile sources\modules\ts\src\ts_gtest.cpp with error pic bellow:
I've tried following several tutorials, but none work cleanly and this is the best I could get stuff to work.
What I did:
Installed Mingw and added C:\Mingw\bin\ to PATH environment variable.
Installed CMake and added it too to PATH.
Extracted OpenCV to C:\ and created forlder C:\opencv\mingwBuild\
In CMake-GUI I define source folder as C:\opencv\sources\ and build folder as C:\opencv\mingwBuild\.
Hit Configure and select Mingw Makefiles, with 'Use default native compilers' (have also specified compilers explicitly and the result is the same.).
Hit Generate, which creates the Makefile.
I open C:\Mingw\msys\1.0\msys.bat to have a console with all variables loaded (have also tried directly from a simple cmd.exe, given that PATH is set for mingw, but I get the same error in compilation). Navigate to C:\opencv\mingwBuild\ and run mingw32-make.
And that's where the error shows up after a while. Any ideas?
Turns ou gTest was not compiling in Mingw for some reason.
As I don't intend to test my code (for now) I removed opencv_ts from instalation (by deselecting it in Cmake, after configuring and before generating).
Someone mentions, in the first link #Dan Masek refers, that GTest has this issue with type conversion under mingw. They say that you can edit ts_gtest.cpp to apply the correct conversion, according to error message. That may be a solution if you need this module.
Another comment in #Dan Masek's second link mentions that gcc's version 5 surpasses the issue, which version 4 has. So, getting a hold of such distro may also be a solution.
For me it seems to be fixed by applying this fix: https://github.com/msk-repo01/opencv/commit/9a1835ce6676836ce278d723da4ff55a8f900ff1
(Also see: https://github.com/opencv/opencv/issues/8105)
The fix basically replaces the "_RTL_CRITICAL_SECTION" by "_CRITICAL_SECTION" for MingW compilers in modules/ts/include/opencv2/ts/ts_gtest.h in the following way:
The lines
// assuming CRITICAL_SECTION is a typedef of _RTL_CRITICAL_SECTION.
// This assumption is verified by
// WindowsTypesTest.CRITICAL_SECTIONIs_RTL_CRITICAL_SECTION.
struct _RTL_CRITICAL_SECTION;
(around line 723 in OpenCV 3.2.0 release from Dec. 2016) are replaced by
# if GTEST_OS_WINDOWS_MINGW
// MinGW defined _CRITICAL_SECTION and _RTL_CRITICAL_SECTION as two
// separate (equivalent) structs, instead of using typedef
typedef struct _CRITICAL_SECTION GTEST_CRITICAL_SECTION;
# else
// assuming CRITICAL_SECTION is a typedef of _RTL_CRITICAL_SECTION.
// This assumption is verified by
// WindowsTypesTest.CRITICAL_SECTIONIs_RTL_CRITICAL_SECTION.
typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
# endif
and
_RTL_CRITICAL_SECTION* critical_section_;
is replaced by
GTEST_CRITICAL_SECTION* critical_section_;
I have application that contain statically linked lua 5.2 inteperpreter (and haven't access to code).
When I trying to write extension with next code:
#define LUA_LIB
#define LUA_BUILD_AS_DLL
#include "lua.hpp"
extern "C"
{
static int test(lua_State* state)
{
return 1;
}
static const struct luaL_Reg functions[] = {
{"test", test},
{NULL, NULL},
};
int __declspec(dllexport) luaopen_test(lua_State* state)
{
luaL_newlibtable(state, functions);
luaL_setfuncs(state, functions, 0);
return 0;
}
}
And compile it with statically linked lua52.lib .
I get "multiple vms detected" error when I trying to require it fromn lua code.
What I can do in this situation?
You can't compile it with statically linked lua52.lib as the main application loads its own version of lua52.lib and when this module is "required", it loads its own copy, which leads to "multiple VMs detected" message.
With statically compiled VM you have two options (on Windows): (1) include all your modules statically, or (2) compile your modules against Lua52.dll, but instead of the actual DLL include a "proxy" DLL that will forward Lua API calls to the methods in the statically compiled executable (the API methods also need to be exported in the executable).
See this thread for the discussion on how the executable needs to be compiled and LuaProxyDllFour page for the proxy DLL.
On Linux you don't need to have a proxy library, but you still need to avoid linking Lua interpreter into the library and export symbols from the executable by using -Wl,-E linker option; see lhf's answer for details.
I'm following the instructions in How to build applications with OpenCV inside the Microsoft Visual Studio but I'm getting errors from the sample code:
error C2065: 'CAP_PROP_FRAME_WIDTH' : undeclared identifier
error C2065: 'CAP_PROP_FRAME_HEIGHT' : undeclared identifier
error C2065: 'CAP_PROP_FRAME_COUNT' : undeclared identifier
I think the identifiers that are undeclared should be declared in highgui so why am I not getting them despite the demo code's #include <opencv2/highgui/highgui.hpp>?
Here are the steps I have taken.
I've unpacked the OpenCV (Version 2.4.6) files into C:\OpenCV, run setx -m OPENCV_DIR C:\OpenCV\Build\x64\vc11 from an elevated command prompt and added %OPENCV_DIR%\bin to my path (following instructions in Installation in Windows). Then using the Property pages (View -> Property Pages or Shift-F4) set to 'All Configurations'
I've added $(OPENCV_DIR)\..\..\include to my C/C++ Additional Include Directories
I've added $(OPENCV_DIR)\lib to the linker Additional Library Directories
I've cut-an-paste the directory listing of the lib files in C:\OpenCV\build\x64\vc11\lib into my input Additional Dependencies
I've copied the sample code from the article into a new C++ console app (with ATL). I had to change one line in the template code from int _tmain(int argc, _TCHAR* argv[]) to int _tmain(int argc, char* argv[])
I think the identifiers that are undeclared should be (are) declared in highgui so why am I not getting them despite the demo code's #include <opencv2/highgui/highgui.hpp>?
Other people having similar issues getting this sample code working in the How to build applications with OpenCV inside the Microsoft Visual Studio note seem to fall over with link errors (e.g. here and here) but I am getting past the linker.
========== EDIT ==========
There appear to be more insurmountable difficulties with the sample code. It is documented as a simple example to load and display an image whose path is supplied as the sole argument to main, while the code listing itself is video code requiring four command line arguments (i.e. it first checks and stops if argc != 5). I've submitted a documentation bug. I think the sample code listing should have been be taken from this: https://github.com/Itseez/opencv/blob/master/samples/cpp/tutorial_code/introduction/display_image/display_image.cpp
Try with CV_CAP_ or cv::CAP_... It looks like there were some changes aiming to improve consistency of constants in OpenCV...
I am using the opencv 2.4.6 and this has helped me do the trick
change CAP_PROP_FRAME_WIDTH into CV_CAP_PROP_FRAME_WIDTH
change CAP_PROP_FRAME_HEIGHT into CV_CAP_PROP_FRAME_HEIGHT
change CAP_PROP_FRAME_COUNT into CV_CAP_PROP_FRAME_COUNT
and similarly if there are any other cap prop keywords into cv cap prop keywords
try this.
I'm still learning how to program but I have a simple question. I have the following code for running an executable COBOL program through C++, but I am getting COBOL errors: 251 and 410
#include <iostream>
#include <windows.h>
using namespace std;
int main(){
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB c=windows.cfg L=WOWRT.DLL");
cout << "\n";
system("pause");
return 0;
}
I assume there must be a very simple reason for this, but I am clueless so far. Any help would be highly appreciated.
Error 410 is a "configuration file not found" error based on Apendix A of the user guide. Are you sure your windows.cfg file is in the directory you're running your code in?
Failing that, error 251 states "Incorrect runtime command" and all the samples I can find have an uppercase C. So maybe change your C program to use to:
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB C=WINDOWS.CFG L=WOWRT.DLL");
and see if that fixes it (a long shot, I know, but I've seen stranger things than that).
Based on update:
I tried changing the c to a C on the C=WINDOWS.CFG, ran it in C++ and directly on the Command Line, no change. I am still looking into the reasons behind this, and I read through tek-tips.com/viewthread.cfm?qid=1119251&page=5 but I couldn't use any of that info. Any extra tips would be gold at this point. THANKS!
A couple of questions:
Has it ever worked in this environment?
Is it failing on both cmdline and within C (just want to clarify)?
Does windows.cfg actually exist in the current directory when you run it?
Are you running it in a directory with spaces (like My Documents)?
Other than that, maybe post the windows.cfg file, though the error seems pretty explicit that it's config file not found rather than error in config file.