[fpc-devel] Fix for an annoying error

[J. Gareth Moreton]

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