Reply To: MWEdit

[Spastic Hamburger]

So that error is now gone even though it was showing up all the time the other day and I didn’t change anything in the build script. Meson didn’t get an update either. Looks like an obscure parsing bug.

No idea how to upload the log. Added the upload commands to the action file but apparently it stops the run at the first error so I’m unable to generate it from the CI.

Edit:

Got the log file. Was looking in the wrong spot. And got it uploaded. I’ll review it shortly!

End Edit

Now we’re back to figuring out how to link DLLs to the executable in the build script. There’s zero documentation on this and nothing I’ve found online works 🙁

With CMake, it’s as simple as this. I have yet to determine how to do it in Meson….Will get back to seeing if I can dig up the answer. If I can’t figure it out, we’ll probably need to switch to CMake as at least I know I can likely get it working in it. I’m starting to get a bit frustrated with trying to make Meson work

As near as I can tell, the Meson script is properly set up. :/

There may be something else going on. It looks like the other DLLs are being linked. At least, I think so. It’s complaining about those two specific symbols for some reason. Currently investigating and doing some trial and error. It’s also possible that the more stringent compilation commands are breaking something due to some bad DLL data. In which case, we’d need to rebuild the DevIL libraries. Unfortunately, NimrodPSI didn’t include any documentation or build scripts for those changes. We may need to totally overhaul how the build system uses DevIL. We’ll need to change things anyways for better 64-bit support

For reference, here are the errors:

[198/198] "link" @MWEdit.exe.rsp
FAILED: [code=1120] MWEdit.exe 
"link" @MWEdit.exe.rsp
project_EsmIconFrame.cpp.obj : error LNK2019: unresolved external symbol __imp_ilutWinLoadImage referenced in function "public: void __cdecl CEsmIconFrame::SetEsmIcon(char const *,bool)" (?SetEsmIcon@CEsmIconFrame@@QEAAXPEBD_N@Z)
project_MWEdit.cpp.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function "public: virtual int __cdecl CMWEditApp::InitInstance(void)" (?InitInstance@CMWEditApp@@UEAAHXZ)
D:\a\MWEdit\MWEdit\IL\DevIL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu-l.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ILUT.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
MWEdit.exe : fatal error LNK1120: 2 unresolved externals

And here are the grep results for those two symbols:

$ grep --recursive --line-number "ilutWinLoadImage"
IL/ilut.h:212:		ILAPI HBITMAP ILAPIENTRY ilutWinLoadImage(const ILstring FileName, HDC hDC);
grep: IL/ILUT.exp: binary file matches
grep: IL/ILUT.dll: binary file matches
grep: IL/ILUT.lib: binary file matches
project/EsmIconFrame.cpp:142:		hBMP = ilutWinLoadImage(FileBuffer, pDC->GetSafeHdc());
project/EsmIconFrame.cpp:144:		hBMP = ilutWinLoadImage((char *const)pFilename, pDC->GetSafeHdc());

And:

$ grep --recursive --line-number "ilInit"
grep: IL/DevIL.exp: binary file matches
IL/il.h:528:ILAPI ILvoid ILAPIENTRY ilInit(ILvoid);
grep: IL/DevIL.dll: binary file matches
grep: IL/DevIL.lib: binary file matches
project/MWEdit.cpp:320:	ilInit();

If we were to enable Unicode support, that would change the first error slightly. ILstring becomes a wchar when _UNICODE is defined:

#ifdef _UNICODE
	#ifndef _WIN32_WCE
		#include <wchar.h>
	#endif
typedef wchar_t *ILstring;
#else
typedef char *ILstring;
#endif //_UNICODE

TCHAR is a typedef of wchar, as I recall, so things may work differently.

Regarding the second symbol, I’m not sure. ilInit() looks like it’s being used properly.

I’ll try reaching out to NimrodPSI via email to see if they can shed any light on the DLLs they built.

The Meson log is also complaining about the install script but we’ll worry about that later. That’s minor in the scheme of things. Worst case scenario, we simply write a shell script or something.