Re: I Can't Get Lua 5.1 and IUP 3.30 to Work With VSCode and GCC on Windows 10 x64

[nerditation <nerditation@...>]

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.