[fpc-devel] Fix for an annoying error
J. Gareth Moreton
gareth at moreton-family.com
Tue Nov 30 23:33:47 CET 2021
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 at 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 at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>>
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
More information about the fpc-devel
mailing list