On 2021-11-30 08:33, J. Gareth Moreton via fpc-devel wrote:
Hi Gareth,
For a while now I've had problems building the i386-win32 compiler under my 64-bit Windows system because one of the packages fails to build - this is because it thinks a statically-imported DLL (done through $linklib) is invalid. Technically it is, but this system DLL (for me, it is named COMMON.DLL and is in one of my system folders, so it's not something I can safely modify or replace) is for 64-bit Windows and is not recognised when building for 32-bit, and the only 'fix' is to comment out the culprit $linklib line in the package source. I've submitted a merge request that generates a warning instead of an error if it detects the DLL is 64-bit for a 32-bit target and vice versa. The checks, however, are very strict (it checks the COFF magic number, which contains a platform target, and the size of the optional header), and an error is still thrown if the DLL is actually corrupted or is for an unknown target. A warning is still thrown because the program that uses it may malfunction, and might be indicative of a bug or a faulty search path for the DLL. https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/91
Semantically, what's the difference between the two cases (a DLL for a different architecture, or a broken DLL)? In both cases the compiled executable may be used on other machines (with proper version of the respective DLL), but it will fail when running it on the machine used for compilation, correct? Shouldn't the compiler handle both cases the same way (possibly issuing a similar warning if the DLL is not found at all)?
Tomas _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
