That was a conundrum I was trying to answer when making the patch. What
is a warning and what is an error?
A lot of the verification code is dependent on compile-time constants
whose values depend on the compiler's target platform, including header
sizes, so any mismatch is an error case, and the checking of header
sizes and the COFF magic number are done together, since the correct
header size is dependent on the magic number's value.
I didn't look too much further beyond the verification code, but if it's
able to detect if a DLL is 32-bit on a 64-bit system and vice versa, I
feel that's a warning rather than error because, in my experience, it's
down to a default system configuration (I got the error on a
freshly-installed machine) rather than something untoward. If the DLL
is missing, that should probably be a warning too and I'll see if I can
make that change. A corrupted DLL is definitely an error though.
I didn't do a verification to see if the DLL is for AArch64, for
example, since that situation is more unlikely. It also starts to bloat
the compiler code.
Either way, using a DLL for a different build of Windows is a warning at
the very least because the project will probably break when you try to
run it.
Gareth aka. Kit
On 30/11/2021 09:47, Tomas Hajny via fpc-devel wrote:
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
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
