lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>this error messages means the linker can't find the function `IupControlsClose`, which should be in `libiupcontrols.a`, so you want add `-liupcontrols` after (in other words, not before) `citybinder.c` since they are referenced from within `citibinder.c`

 

Where? The Makefile? I can’t get anywhere with the Makefile because of that “supported emulations” error. The file ‘citybinder.c’ doesn’t show up in my .json files.

 

Also, when I perform a search in the MyLibs folder (where I put my libraries and Lua) in File Explorer for ‘IupControlsClose’, it finds nothing. It easily finds ‘IupControlsOpen’ in files and I would’ve expected both commands to be in the same file.

 

If I can ditch the Makefile and just use the .json files, that’s good enough for me right now.  

 

I’ve now got my compiler args set to the following, which cleared up all except the “undefined reference to ‘IupControlsClose’” error when I try to build (using .json files, not Makefile):

 

"compilerArgs": [

                "-IC:/MyLibs/lua-5.1/include",

                "-IC:/MyLibs/im/include",

                "-IC:/MyLibs/cd/include",

                "-IC:/MyLibs/iup/include",

                "-LC:/MyLibs/lua-5.1",

                "-LC:/MyLibs/im",

                "-LC:/MyLibs/im/Lua51",

                "-LC:/MyLibs/cd",

                "-LC:/MyLibs/cd/Lua51",

                "-LC:/MyLibs/iup",

                "-LC:/MyLibs/iup/Lua51",

                "-llua5.1",

                "-liup",

                "-liuplua51",

                "-liupcontrols",

                "-liupluacontrols51",

                "-lcdlua51",

                "-lcd",

                "-liupluacd51",

                "-liupcd",

                "-liupluaim51",

                "-liupim",

                "-lpsapi",

                "-lim",

                "-liupcd",

                "-liup", //DUPlicate!

                "-lz",

                "-lfreetype6",

                "-lkernel32",

                "-luser32",

                "-lgdi32",

                "-lwinspool",

                "-lcomdlg32",

                "-lcomctl32",

                "-luuid",

                "-loleaut32",

                "-lole32",

                "-ladvapi32",

                "-lshell32",

                "-lws2_32"

            ]

 

 

 

 

From: nerditation
Sent: Monday, November 1, 2021 6:51 AM
To: lua-l@lists.lua.org
Subject: Re: I Can't Get Lua 5.1 and IUP 3.30 to Work With VSCode and GCC on Windows 10 x64

 

On 2021/10/29 3:38, Kaz wrote:

>  

>

> I noticed some other ‘-l’ items that weren’t working right when trying to debug the original app. I took them from the Makefile and put them into c_cpp_properties.json. Those were "-lcdluaiup" and "-lcdiup".

>

>  

>

> I don’t have any files called ‘libcdluaiup.a’ or ‘libcdiup.a’ in C:\MyLibs\cd, however in the ‘include’ subfolder, there’s one called cdluaiup.h. C:\MyLibs\iup DOES have a file called ‘libiupcd.a’ and the ‘Lua51’ subfolder has one called ‘libiupluacd51’, so I replaced "-lcdluaiup" and "-lcdiup" with “-liupluacd51” and “-liupcd” in case the file names have been changed over the years

 

you are using the correct libraries. they have different names probably due to different

packaging policies between the official upstream binary distribution and the platform

where the Makefile were originally developed.

 

 

 

 

 

>  

> I don’t know if the order of ‘-l’ items is wrong or if I’m missing some things. How do you tell what’s dependent on what? I think adding “-lfreetype6” helped get rid of some errors, but I’d like to know if there’s a specific way of determining what to add.

>

 

that's the unfortunate inconvenience of static linking using a linker with long history

and legacy behavior (the GNU linker in this case): you have to manually ensure the correct

topological order of the dependency graph between all the libraries. it's tedious,

but not really difficult. you just need to figure out where the missing reference symbols are

and append the library name to the linker command line. just be aware there's a limit on the

length of a command line imposed by the operating system. if your are building a REALLY large

project, you might need to use a response file to workaround this limitation.

 

 

for example:

 

 

> C:/Users/name/Desktop/Apps/src/citybinder.c:683: undefined reference to `IupControlsClose'

 

this error messages means the linker can't find the function `IupControlsClose`, which should be in

`libiupcontrols.a`, so you want add `-liupcontrols` after (in other words, not before) `citybinder.c`

since they are referenced from within `citibinder.c`

 

 

> C:/MyLibs/cd/libcd.a(cdirgb.o):cdirgb.c:(.text+0x49f3): undefined reference to `FT_Set_Transform'

> C:/MyLibs/cd/libcd.a(cdirgb.o):cdirgb.c:(.text+0x4a03): undefined reference to `FT_Load_Char'

> C:/MyLibs/cd/libcd.a(cdirgb.o):cdirgb.c:(.text+0x4bbf): undefined reference to `FT_Load_Char'

 

these functions with `FT_` prefix are from freetype, as you already figured out. you should add that

somewhere after `-lcd`

 

 

> C:/MyLibs/cd/libcd.a(zip.o):zip.c:(.text+0x1408): undefined reference to `crc32'

> C:/MyLibs/cd/libcd.a(zip.o):zip.c:(.text+0x151c): undefined reference to `deflate'

> C:/MyLibs/cd/libcd.a(zip.o):zip.c:(.text+0x1a59): undefined reference to `deflateEnd'

> C:/MyLibs/cd/libcd.a(unzip.o):unzip.c:(.text+0x1e48): undefined reference to `inflate'

 

these are functions from "zlib" and the linker option should be `-lz` in mingw32/64, if I

recall correctly.

 

 

> C:/MyLibs/cd/libcd.a(cdwprn.o):cdwprn.c:(.text+0x421): undefined reference to `__imp_DeviceCapabilitiesW'

 

this one is interesting, it's a Windows API, and the `__imp_` prefix means it's from a so called

"import library" of some DLL, the function name is `DeviceCapabilities`, and the `W` suffix means

it is the Unicode version of the API. google the function name, you'll find the official MSDN page.

 

the document says you should link against `winspool.lib`, which is a visual C++ format library file,

and it translates to `-lwinspool` under mingw32/64 according to mingw convention.

 

 

>  

>

> If I try using the Makefile, I get this error still:

>

>  

>

> ld.exe: unrecognised emulation mode: windows

>

> Supported emulations: i386pep i386pe

>

 

well, apparently your Makefile was written with very old GNU toolchain. if you intend to maintain

the Makefile, you probably want to hand it over to a C or C++ programmer who knows GNU make and

the mingw toolchain well.