As long as it doesn't break something in the package... that works,
thanks! That's been the bane of i386-win32 testing for ages!
Gareth aka. Kit
On 30/11/2021 22:03, Michael Van Canneyt via fpc-devel wrote:
Gareth,
I removed the $linklib for common.dll.
Michael.
On Tue, 30 Nov 2021, J. Gareth Moreton via fpc-devel wrote:
Well, running the program on the target system isn't a guaranteed
success even if there's no error on the compilation system because
the DLL in question may be different (or missing).
If it turns out that common.dll is not required, then the maintainer
of the package should probably remove the $linklib line, otherwise
I'm not sure. If I'm right in thinking, if the DLL is missing or
incompatible, it won't read the exports table and so even if just a
warning is raised, it may cause a cascade error if any of its
functions are used in the unit because they're not declared.
Gareth aka. Kit
On 30/11/2021 16:22, Michael Van Canneyt via fpc-devel wrote:
On Tue, 30 Nov 2021, J. Gareth Moreton via fpc-devel wrote:
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.
Personally, I think that reverting to a warning was a mistake.
You have no guarantee that the resulting program will run if you
ignore the
"error":
Not on the system where you compiled, not on the system where you
will run the program.
For your particular problem: I looked at the source code of the
oracle unit.
As far as I can see there is no need to include the common.dll in the
linklib statements, all that should be linked is the oracle dll. It
may be a better solution simply to remove that line.
Michael.
_______________________________________________
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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
