 |
lua-l archive |
|
|
||
|
I looked at your example and tried some things. Added some headings to make it easier to read. FILES I DOWNLOADED ======================== I was told by a commenter elsewhere that the app I’m working on looks like it uses static libraries. There is a file called iuplua5.exe in the 'src' folder though and I'm not sure why since aren’t .exe files related to dynamic libraries? It gives errors if I try to open the main Lua file in it. Since there are #include statements in the C file for CD and IM header files (the IM ones, #include "iupluaim.h", and #include <imlua.h>, appear faded in VSCode so I don’t know if that means they aren't getting used anywhere), I downloaded those too. Since the app uses Lua 5.1 and I want to stick with that while updating IUP, the files I grabbed are named slightly differently, but this is what I unzipped to my folder C:\MyLibs (I put each into its own subfolder since the IUP site said “Do not extract different pre-compiled binaries in the same directory, create a subdirectory for each one” at www.tecgraf.puc-rio.br/iup/en/buildwin.html under the header “Pre-compiled Binaries”): lua-5.1.4_Win64_mingw4_lib.zip iup-3.30_Win64_mingw6_lib.zip im-3.15_Win64_mingw6_lib.zip cd-5.14_Win64_mingw6_lib.zip I kept mingw and the libraries outside of the Program Files folder since I read about potential problems with the name "Program Files" containing a space and/or being too long. I can't remember the context. Maybe it was when using -I or -L in VSCode's .json files. For IUP, CD, and IM, I unzipped the following contents into their “Lua51” subfolders, like how the folders are structured on the SourceForge file download pages: iup-3.30-Lua51_Win64_mingw6_lib.zip im-3.15_Win64_mingw6_lib.zip cd-5.14-Lua51_Win64_mingw6_lib.zip I hope that was the correct thing to do. I'm not sure if I added the right directories to Path under environmental variables or if it matters when I'm using -I and -L to tell VSCode where to look. JSON FILES ======================== For the c_cpp_properties.json, I noticed that the default configuration was '"name": "Win32"', so I changed that to '"name": "mingw64-static-link"' like you said. Since it's a C file, not C++, don't I have to use gcc.exe as the compiler? If I just put that in the c_cpp_properties.json, VSCode can't find it, so I used '"compilerPath": "C:/mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/bin/gcc.exe"'. I thought that having added 'C:\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin' to Path in Environment Variables would let me use '"compilerPath": "gcc.exe"' without a problem, but I guess that's not how Environment Variables work. Just to clarify in case anyone else is researching this stuff like I did, “-I” points to “include” folders where .h files are and “-L” points to where the .a files are, right? To "compilerArgs" I added this list that points to the locations of the .h and .a files: "-IC:/MyLibs/lua-5.1/include", "-IC:/MyLibs/cd/include", "-IC:/MyLibs/im/include", "-IC:/MyLibs/iup/include", "-LC:/MyLibs/lua-5.1", "-LC:/MyLibs/cd", "-LC:/MyLibs/cd/Lua51", "-LC:/MyLibs/im", "-LC:/MyLibs/im/Lua51", "-LC:/MyLibs/iup", "-LC:/MyLibs/iup/Lua51", I read that "Order does matter when you use several options of the same kind; for example, if you specify -L more than once, the directories are searched in the order specified. Also, the placement of the -l option is significant" (https://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html), but I'm not sure how to order it. Is it by order of initialization in the C script? Dependencies? I read about IUP having dependencies on CD and IM. Do you write '-I' directories first, then '-L' directories or do you group the directories by folder? I’ve seen ** used in .json files to make VSCode search subfolders. I tried shortening that code by writing: "-IC:/MyLibs/**", "-LC:/MyLibs/**" But that gave me errors so I changed it back. Also, to "compilerArgs", I added the following list, which I got from the app's Makefile: //cd_LIBS= "-lcdlua51", "-lcdluaiup51", "-lcd", "-lcdiup", //im_LIBS= "-lim", //iup_LIBS= "-liuplua51", "-liupluacontrols51", "-liupluaim51", "-liup", "-liupcontrols", "-liupim", //lua_LIBS= "-llua", //win_LIBS= "-lpsapi", "-lgdi32", "-luser32", "-lkernel32", "-lole32", "-lcomctl32", "-ladvapi32", "-lshell32", "-lws2_32" Should the .json also have: "cStandard": "c17", "cppStandard": "c++17" DEBUG ERRORS ======================== I get a few warnings/errors I don't know how to fix after running build/debug with that tasks.json: 558:7: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] if ((int)(info.hInstApp) > 32) { ^ 683:3: warning: implicit declaration of function 'IupControlsClose'; did you mean 'IupControlsOpen'? [-Wimplicit-function-declaration] IupControlsClose(); ^~~~~~~~~~~~~~~~ IupControlsOpen ld.exe: cannot find -lcdluaiup51 ld.exe: cannot find -lcdiup ld.exe: cannot find -llua Why can't it find those? cdluaiup51.h and cdiup.h are in 'C:\MyLibs\cd\include' and lua.h is in 'C:\MyLibs\lua-5.1\include'. I specified both directories with '-I'. Speaking of 'ld.exe', I noticed that when I try to build by running the Makefile, I get this error (I don't know how to fix this) and I wonder if it has anything to do with the problem: ld.exe: unrecognised emulation mode: windows Supported emulations: i386pep i386pe I noticed that "-luuid" and "-lcomdlg32" you mentioned weren't in the Makefile so I changed c_cpp_properties.json "compilerArgs" to say: //cd_LIBS= "-lcdlua51", "-lcdluaiup51", "-lcd", "-lcdiup", //im_LIBS= "-lim", //iup, lua, and win LIBS= "-liuplua51", "-llua", "-liup", "-liupcontrols", "-liupluacontrols51", "-liupluaim51", "-liupim", "-lpsapi", "-lgdi32", "-luser32", "-lkernel32", "-lcomctl32", "-lcomdlg32", "-lole32", "-luuid", "-ladvapi32", "-lshell32", "-lws2_32" I tried to order it like your example, but I've got a lot more items here, so I don't know how to. I got the same errors trying to debug with this version. RESPONSES TO PREVIOUS EMAIL ======================== > 4. if you are using static linking, in 'src/main.cpp', don't forget to add 'iuplua_open','iupcontrolslua_open', etc, into the package.preload' table so that Lua code have access to IUP. I searched the C file, but the text 'package.preload' doesn't appear. Is that a problem? I found 'iuplua_open(L);' and 'iupcontrolslua_open(L);' in the function 'static void iuplua_openlibs (lua_State *L)' > you need the correct development packages to be able to build, not just the 'header files'. Do I need more than what was contained in the .zip files I listed? Those had .a files too. Do I need to download the .zip files containing the .dll and .exe files? > you can use vscode (togother with gdb from mingw toolchain) to debug C/C++ code, but you need to have debugging functionality built into your app via Lua debug API in order to debug Lua code. How do I know if I have that? In VSCode, I have the Lua extension by sumneko to use Intellisense. > a correct Makefile will help you build the program, but, AFAIK, vscode still need to be configured manually to be able to use the debugger integrated within vscode. I know there are instructions on setting up IUP for Visual Studio, but it'd be nice if there was an updated tutorial for Visual Studio Code since a lot of people seem to be using it and it can't be set up with libraries in the same way. From: nerditation On 2021/10/17 5:00, Kaz wrote: >> [...] I'm not sure I understand your problem properly, what do you mean by "C script" and "calls the header files"?[...] > > > > Most of the app’s source files are Lua files, but one is .c. The file written in C has a bunch of “#include” statements like #include “iup.h” and it contains some global variables. The actual app code, beyond setting up includes and some globals, is in the Lua files. > > if the app contains only 1 single C source file, it should be really easy to set up the toolchain and editor. please refer to the example in my previous post. feel free to reach me off list if you have trouble understanding the instructions. > > I’ve since downloaded and installed the .h header files for Lua 5.1 (the app uses this version and the code uses “getn” a lot, which was depreciated in later versions of Lua), IUP, CD, and IM like in the Makefile included in the app’s source files, added the “include” and “Lua51” directories to the “path” section of Environment Variables, but VSCode still can’t find them. > > you need the correct development packages to be able to build, not just the 'header files'. also you need to configure the tools correctly, including vscode the editor, not only the Makefile. > >> [...] what are you trying to debug, your app's source code (in C/C++) or the Lua code that run inside your host app? > > VSCode [...] > > I don’t know which one I’m supposed to debug. I’m just trying to get VSCode to do something right and find the .h files. I tried using debug on the C file, but that didn’t work. I tried running the app’s main Lua file with the iuplua interpreter but that gives me errors too. I tried to compile, but that doesn’t work. I tried using the app’s Makefile after making some adjustments (the folder structures of the library files I downloaded weren’t the same. There were no folders called “lib”), but nothing can find the .h files. > you can use vscode (togother with gdb from mingw toolchain) to debug C/C++ code, but you need to have debugging functionality built into your app via Lua debug API in order to debug Lua code. a correct Makefile will help you build the program, but, AFAIK, vscode still need to be configured manually to be able to use the debugger integrated within vscode. > >> [...] if your app contains native code, you should use the library packages, either static or dynamic, but not the binary ones. [..] > > The C file contains #include <windows.h>. Does that mean it contains “native code”? > by native code, I simply mean a program with C/C++ source files (instead of pure Lua files). |