Hi everyone,

This might be my own configuration, but can people check that i386-win32 works properly? I tried to build it to test one of my new optimisations, but got a failure when building the trunk (without my optimisations).

Building using "make all install OS_TARGET=win32 CPU_TARGET=i386 FPC=C:\FPC\3.2.0\bin\i386-win32\fpc.exe" (since my machine is 64-bit Windows)

...
[ 20%] Compiled package odbc
Start compiling package oracle for target i386-win32.        Compiling oracle\BuildUnit_oracle.pp
       Compiling .\oracle\src\oratypes.pp
       Compiling .\oracle\src\ocidyn.pp
       Compiling .\oracle\src\oci.pp
       Compiling .\oracle\src\oraoci.pp
External command
"C:/Users/garet/Documents/programming/fpc/compiler/ppc386.exe -Twin32 -FUoracle\units\i386-win32\
-FuC:\Users\garet\Documents\programming\fpc\rtl\units\i386-win32\ -Fuoracle\src -Fioracle\src -Ur -Xs -O2 -n -di386 -dRELEASE -XX -CX -Sc -viq oracle\BuildUnit_oracle.pp" failed with exit code 1. Console output: Target OS: Win32 for i386
Compiling oracle\BuildUnit_oracle.pp
Compiling .\oracle\src\oratypes.pp
Compiling .\oracle\src\ocidyn.pp
Compiling .\oracle\src\oci.pp
Compiling .\oracle\src\oraoci.pp
oraoci.pp(1437) Error: Invalid DLL C:\windows\system32\common.dll, invalid header size
oraoci.pp(1437) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

The installer encountered the following error:
Compilation of "BuildUnit_oracle.pp" failed
make[2]: *** [smart] Error 1
make[2]: Leaving directory
`C:/Users/garet/Documents/programming/fpc/packages' make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `C:/Users/garet/Documents/programming/fpc' make: *** [build-stamp.i386-win32] Error 2

It seems that the Oracle package is upset about one of my DLLs. Anyone got any ideas?  It's blocking more complete testing of my changes (and other things like Tomas' console colour patch).

Gareth aka. Kit

Just now successfully compiled both i386-win32 and x86_64-win64 from trunk r47572 with release FPC 3.2.0.

Op 2020-11-25 om 00:37 schreef J. Gareth Moreton via fpc-devel:

Compiles fine here (but I build with parallel options, and I don't have that dll).

Note that you seem to be building win32, but on a win64 system c:\windows\system32 is 64-bit ? It could be that the windows\system32 part that you see is virtualized, but you could see if you check the type of that DLL.

Aah, typical!  C:\Windows\System32 is supposed to be for 32-bit DLLs, while C:\Windows\System is 64-bit.  Question is, what can I do to resolve it?  I'm not even sure what Common.dll is for.

Gareth aka. Kit

J. Gareth Moreton via fpc-devel schrieb am
Mi., 25. Nov. 2020, 09:51:

Aah, typical! C:\Windows\System32 is supposed to be for 32-bit DLLs, while C:\Windows\System is 64-bit. Question is, what can I do to resolve it? I'm not even sure what Common.dll is for.

Wrong.

System32 -> Host Bitness
System -> 16-bit remnants
SysWOW32 -> 32-bit on 64-bit

Regards,
Sven

J. Gareth Moreton wrote

Aah, typical!  C:\Windows\System32 is supposed to be for 32-bit DLLs, while C:\Windows\System is 64-bit.  Question is, what can I do to resolve it?  I'm not even sure what Common.dll is for.

SYSTEM32 has 64 bit files on 64 bit Windowsi, 32 bit files go to SysWOW64. I'm not sure, what SYSTEM was for. And Windows Virtualises access to SYSTEM32 to SysWOW64 for 32 bit programs. I specifically tested with 32 and 64 bit Total Commander - they show different content for C:\WINDOWS\SYSTEM32 directory.
So if the compiler is 32 bit fpc, then actual dll should be C:\Windows\SysWOW64. And if that is 64 bit dll for some reason, then that could cause problems.

J. Gareth Moreton wrote

Aah, typical!  C:\Windows\System32 is supposed to be for 32-bit DLLs, while C:\Windows\System is 64-bit.  Question is, what can I do to resolve it?  I'm not even sure what Common.dll is for.

Well, I don't think that it works this way - 32-bit applications cannot access the directory with the 64-bit versions as far as I know (they're always directed to the 32-bit versions in the background on the operating system level). In any case, checking the particular library seems to be the best way forward. You should be able to find the DLL "Manufacturer" and "Description" information within the binary (either using some tools able to extract and display it, or even just looking into the file with a binary file viewer).

Tomas

Damn - I never thought to fully confirm that.

So what I've found so far - there's a copy in the following directories:

-
C:\Windows\System32\DriverStore\FileRepository\xtucomponent.inf_amd64_614515f4e6eb21a1
- C:\Windows\SysWOW64

Both seem to be identical, unless one is a simple mirror of the other.  There is no actual copy in C:\Windows\System32.

File description:    Common
Product name:    Intel(R) Extreme Tuning Utility Product version:    7.0.0.16
Copyright:    Copyright(C) 2007 - 2020. Intel Corporation. All Rights Reserved

That's the only useful stuff I found.  Sorry to sound like such a novice.  I have never come across this error before and am not sure how to resolve it without breaking something critical.

The other option would be to manually disable compiling the package that triggers it.  Any tips on that? (Granted I rather get it to compile successfully)

Gareth aka. Kit

Op 2020-11-25 om 18:10 schreef J. Gareth Moreton via fpc-devel:

Easiest: do an install of the relevant oracle stuff on a scratch machine/VM, collect DLLs and put them in a directory.

Add that directory to the front of the %PATH% in the build script., and that dll will be found and not the system one.

(

All my path changing scripts have the same structure:

@echo off

if "%OLDPATH%" neq "" goto :nosave
set OLDPATH=%PATH%
:nosave
SET PATH=%OLDPATH%
PATH c:\pp32\bin\i386-win32;%PATH%

This allows to undo the change by just SET PATH=%OLDPATH%, and if I first use cygwin and then FPC, that they are not both in the path as the same time

)

Sure thing - I'll give that a try.

Looks like this is my first true experience with DLL Hell!

Gareth aka. Kit

From packages\oracle\README.txt:

"For the older 'oraoci' unit to compile you need oracle server installed, these units was tested and performed on Oracle 8.0.1.5 Standard server. One developer license of Oracle server is free of charge..."

Looks like the common.dll is not the right one that is needed to compile.

Well, I found a temporary solution.  installing 32-bit Oracle libraries didn't fix the problem, so I simply commented out the $linklib entry in the culprit file.  I didn't have any of the other files it listed anyway!

Gareth aka. Kit

Thank you for sending me the DLL. The problem is that the DLL is a 64-bit one, but is for some reason located in the virtualized 32-bit System32 directory.

Regards,
Sven

I figured it was something like that.  I'm not sure which installer put it there, or if moving it to the System32 directory will cause something to catastrophically fail!

Given that it seems to just silently ignore the issue of the DLL doesn't exist, would a warning be better for an invalid DLL or should it remain an error?

Gareth aka. Kit

Good question. I don't know why we have the DLL scanner anyway, considering that it also works without the DLL present...

Regards,
Sven

The fact that it doesn't seem to throw a warning if the library is missing is a bit weird.  Or if it does, I haven't noticed the message.

Gareth aka. Kit