Hi,

C:\devel\fpc\trunk>git log -1
commit a77f5221f341b32bb964c03dc61c1e80b71714dd (HEAD -> main, origin/main, origin/HEAD)
Author: florian
Date: Sat Aug 21 20:36:29 2021 +0200

C:\devel\fpc\trunk>make clean
....
C:\devel\fpc\trunk>make all
...
[ 19%] 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:/devel/fpc/trunk/compiler/ppc386.exe -Twin32 -FUoracle\units\i386-win32\
-FuC:\devel\fpc\trunk\rtl\units\i386-win32\ -Fuoracle\src -Fioracle\src -Ur -Xs -O2 -n -g -gl -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:/devel/fpc/trunk/packages' make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `C:/devel/fpc/trunk'
make: *** [build-stamp.i386-win32] Error 2

All this on Windows 10 Home 64-bit 21H1 build 19043.1165

It seems that this dll is not on present my system in the system32 folder. C:\>dir common.dll /s
Volume in drive C is Windows
Volume Serial Number is 0C94-A215

Directory of C:\Windows\System32\DriverStore\FileRepository\xtucomponent.inf_amd64_4cb858d369dc9598 24-02-2021 10:18 425.024 Common.dll

Directory of C:\Windows\System32\DriverStore\FileRepository\xtucomponent.inf_amd64_98dcbf2de4d7f44b

30-10-2019 08:39 367.896 Common.dll

Directory of C:\Windows\SysWOW64

24-02-2021 10:18 425.024 Common.dll

Since when is this dll needed to build fpc?
Can I circumvent this requirement?
Am I required to install some additional software?

This is a problem I run into all the time  Basically, the DLL is 64-bit and hence is invalid in a 32-bit binary.  This can be bypassd by commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp

Gareth aka. Kit

AM J. Gareth Moreton wrote

This is a problem I run into all the time Basically, the DLL is 64-bit and hence is invalid in a 32-bit binary. This can be bypassd by commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp

Tha cannot be a real solution.

Also, that line has been in that unit for at least 8 years AFAICS. But I have build fpc trunk several times in the past before, without such an error.
And yes, I've built trunk with 3.2.2 as a starting compiler before.

Since the last time I built trunk, the only change I made to my computer is installing a git client (commandline version). My windows is up to date.

So, this baffles me.

AM Bart wrote

So, this baffles me.

As does this:

C:\devel\fpc\trunk\packages\oracle>type README.txt These units provides interface to Oracle Call Interface.

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...

Unit oraclew contains some procedures and functions, which makes usage of oraoci not so painfull... But - if you wanna to program in RAW OCI, you really can ;)

The oci and ocidyn units are a complete conversion from Oracle's .h files. The former links statically to the library, the latter dynamically.

You need to have oracle lib directory in ldpath, too, or you can this path set in Makefile.fpc (is commented there)

I never ever had oracle server installed, but yet in the past I was able to build fpc and this build includes the oracle units:

The last time I successfully built and installed a 32-bit fpc trunk was apparently in april this year:

C:\>dir pp\units\i386-win32\oracle\
Volume in drive C is Windows
Volume Serial Number is 0C94-A215

Directory of C:\pp\units\i386-win32\oracle

03-04-2021 23:35 <DIR> .
03-04-2021 23:35 <DIR> ..
03-04-2021 23:32 510.096 libimpoci.a
03-04-2021 23:32 8 libimporaoci.a 03-04-2021 23:32 229.323 oci.o
03-04-2021 23:32 651.520 oci.ppu
03-04-2021 23:32 499.448 ocidyn.o
03-04-2021 23:32 462.192 ocidyn.ppu
03-04-2021 23:32 31.248 oraoci.o <==== 03-04-2021 23:32 71.842 oraoci.ppu <==== 03-04-2021 23:32 36.987 oratypes.o
03-04-2021 23:32 12.234 oratypes.ppu

Here's the unit contents of the crosscompiler build of today: C:\>dir pp\units\x86_64-win64\oracle
Volume in drive C is Windows
Volume Serial Number is 0C94-A215

Directory of C:\pp\units\x86_64-win64\oracle

04-04-2021 13:47 <DIR> .
04-04-2021 13:47 <DIR> ..
22-08-2021 12:02 423.976 libimpoci.a
22-08-2021 12:02 223.272 oci.o
22-08-2021 12:02 662.054 oci.ppu
22-08-2021 12:02 525.671 ocidyn.o
22-08-2021 12:02 463.170 ocidyn.ppu
22-08-2021 12:02 24.878 oraoci.o
22-08-2021 12:02 71.849 oraoci.ppu
22-08-2021 12:02 36.389 oratypes.o
22-08-2021 12:02 12.296 oratypes.ppu

Interestingly it does not contain a "libimporaoci.a" like the 32-bit version does.

AM J. Gareth Moreton wrote

This is a problem I run into all the time Basically, the DLL is 64-bit and hence is invalid in a 32-bit binary. This can be bypassd by commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp

I have now finally resorted to that.
Wrote a simple program to do that for me (no sed on windows). Then adjusted my build script to run that program, build fpc, then do a "git restore".

This, of course is an insane and stupid solution.

It would be very much appreciated if anybody can explain why this (building trunk) worked before, but does not anymore. Also can anybody explain why all the other {$linklib xxx} lines do NOT cause compilation and linking to fail??

Hi,

23.08.2021 0:46, Bart via fpc-devel:

I have now finally resorted to that. Wrote a simple program to do that for me (no sed on windows).

Just in case:

http://gnuwin32.sourceforge.net/packages/sed.htm

Regards,
Nikolai

Are you sure this common.dll is 32 Bit? C:\Windows\SysWOW64 may contain only 32 Bit DLLs.

AM Florian Klämpfl wrote

Are you sure this common.dll is 32 Bit? C:\Windows\SysWOW64 may contain only 32 Bit DLLs.

I have no idea how to test this.

Mind you: a simple test program with {$linklib common} fails for me for either 32 or 64, wether or not I supply the path to syswow64 in the -Fl parameter.

What is different about the build system for fpc, than just compiling a simple test program?
Why doesn't linking fail (for all (cross)targets: win32, win64, wince), when none of the other statically linked libs in that unit is present on my system?

Does anybody have a common.dll in \windows\system32 at all? None of my other 2 Win10 machines (hardware, not VM) does have any common.dll anywhere on its system.

A google search learns that common.dll is mostly used by games? Is the common lib that is needed a specific oracle lib?

This is so frustrating.

Hi *,

Not directly related at all, but while trying to have a look at the compiler code related to the error message about the DLL header size, I realized that there are quite a few error messages (including this one) hardcoded in ogcoff.pas instead of having these messages in errore.msg and thus allowing translation, centralized management of these message texts, etc. It would be probably useful to fix that (I guess that some volunteer should be able to provide patches for that)...

Tomas

Bart wrote

Does anybody have a common.dll in \windows\system32 at all?

I don't have it, neither in system32 nor in SysWOW64.

Just pulled the current revision of fpc-trunk, and did not observe this error (Win 10, fpc3.2.2 32-bit bootstrap compiler)

Also, the message is wrong.
It says the file in that location has the wrong header, but the file does not even exist in that location.

Does it exist in C:\Windows\SysWOW64\ on your machine?

Tomas

PM Werner Pamler wrote

> Does anybody have a common.dll in \windows\system32 at all? I don't have it, neither in system32 nor in SysWOW64.

OK.

Just pulled the current revision of fpc-trunk, and did not observe this error (Win 10, fpc3.2.2 32-bit bootstrap compiler)

I expected as much, since nobody else complained about this error. AFAIK the syswow64 directory is not in my %PATH%.

Unfortunately the "OPT=-vut" does not work (no output whatsoever) when this package is built, so no way to determine where it searches (and does not find: the errormessage is wrong w.r.t. that) and fails for 32-bit, not where it finds and succeeds for 64-bit and arm-wince.

PM Tomas Hajny wrote

Does it exist in C:\Windows\SysWOW64\ on your machine?

Yes, there is a common.dll there.
I think that syswow64 is not in my %PATH%, but currently I'm at work and cannot check.

I also do not know how to examine wether this one is 32 or 64 bit.

(And even that one is 32-bit and the header is wrong, the errormessage would still be wrong, since it explicitely mentions C:\Windows\system32).

Use objdump, provided with FPC:

C:\lazarus\fpc\3.2.0\bin\x86_64-win64\objdump -f c:\Windows\SysWow64\combase.dll

c:\Windows\SysWow64\combase.dll: file format pei-i386 architecture: i386, flags 0x0000012f:
HAS_RELOC, EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGED start address 0x1013c090

C:\lazarus\fpc\3.2.0\bin\x86_64-win64\objdump -f "c:\Program Files\Common Files\microsoft shared\VGX\VGX.dll"

c:\Program Files\Common Files\microsoft shared\VGX\VGX.dll: file format pei-x86-64 architecture: i386:x86-64, flags 0x0000012f:
HAS_RELOC, EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGED start address 0x00000001800a42a0

(note the file format on the first line)

Michael.

The problem is that MS Windows employs a special trickery by which the path to c:\windows\system32 (almost surely in your PATH) translates to c:\windows\SysWOW64 _for_32-bit_binaries_ (only!). So in reality, that directory _is_ in your PATH.

Unfortunately the "OPT=-vut" does not work (no output whatsoever) when this package is built, so no way to determine where it searches (and does not find: the errormessage is wrong w.r.t. that) and fails for 32-bit, not where it finds and succeeds for 64-bit and arm-wince.

It doesn't need to find it for 64-bit or arm-wince. As far as I know, it works like this: If the referenced DLL is found, the compiler builds the import library by scanning the found DLL, thus creating a complete and validated file guaranteed to work (on your machine). If the DLL is found, but it is not correct (either because it is somehow invalid, or because it doesn't contain the symbols / functions etc.), the compiler tells you about this issue, because it means that an attempt to run the compiled binary would fail with possibly obscure errors (compared to an error message stating that a required DLL is missing). If the referenced DLL is not found during compilation, the compiler tries to build the import library "blindly", just based on assumptions formulated in the source code.

Tomas

The compiler finds the DLL by looking to C:\Windows\system32. As mentioned in another e-mail, the fact that this request is redirected to C:\Windows\SysWOW64 instead by the underlying operating system is a MS Windows trickery - feel free to complain at Microsoft. ;-)

Tomas

PM Tomas Hajny wrote

The compiler finds the DLL by looking to C:\Windows\system32. As mentioned in another e-mail, the fact that this request is redirected to C:\Windows\SysWOW64 instead by the underlying operating system is a MS Windows trickery - feel free to complain at Microsoft. ;-)

OK, just for my understanding of this:
I cannot see the file there (system32)
FPC looks for it there
Windows just says it's there (and silently redirects to syswow64 folder) FPC looks at file, sees it's wrong, tells me the file in system32 is wrong.

Does that imply that, when I have a 32-bit program do a FindFirst for common.dll in the system32 folder, Windows just tells the program that the file is there?

PM Tomas Hajny wrote

The problem is that MS Windows employs a special trickery by which the path to c:\windows\system32 (almost surely in your PATH) translates to c:\windows\SysWOW64 _for_32-bit_binaries_ (only!). So in reality, that directory _is_ in your PATH.

Nice...

If the referenced DLL is not found during compilation, the compiler tries to build the import library "blindly", just based on assumptions formulated in the source code.

So:
- 32-bit: it finds common.dll (thank you MS), which is the wrong one for the intended purpose (functions not found?) the compilation fails
- 64-bit and arm-wince: it does not find common.dll (nor any of the other ones), but it can construct an importlibrary based on the sourcode and compilation succeeds (running a prgram that uses the unit will fail, since the libraries are just not on my system)

Should I start the build process with a %PATH% that does NOT have C:\Windows\system32 in it?

Just move common.dll from SysWOW64 to system32. The file is placed wrongly by some installer.

Yuriy.

You probably cannot see it there if looking there by using a 64-bit application. If you use a 32-bit build of some file manager, you'd probably see it there as well.

Yes, it does.

Tomas

Op 8/23/2021 om 3:11 PM schreef Bart via fpc-devel:

For compilers this is always more difficult, since the mapping must match the target system rather than the host binary.

True, but FPC already deals with that difference (and avoids this redirection using the respective Win32 API function if cross-compiling from Win32 to Win64).

Tomas

PM Yuriy Sydorov wrote

Just move common.dll from SysWOW64 to system32. The file is placed wrongly by some installer.

If I understand Tomas correctly then that would not make any difference: wether or not that specific common.dll is in system2 or syswow64, Windows just makes fpc believe it is in system32 anyway, AND fpc decides this is the wrong common.dll and aborts.

PM Michael Van Canneyt wrote

Use objdump, provided with FPC:

Thanks!

C:\devel\fpc\trunk>objdump -f \windows\SysWOW64\Common.dll

\windows\SysWOW64\Common.dll: file format pei-x86-64 architecture: i386:x86-64, flags 0x0000012f:
HAS_RELOC, EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGED start address 0x0000000000000000

It says it's a 64-bit dll?

PM Bart wrote

Should I start the build process with a %PATH% that does NOT have C:\Windows\system32 in it?

I tried to build with only the path to the starting compiler in %PATH%:

PATH /devel/fpc/3.2.2/bin/i386-Win32
make clean
make all OPT=...

That failed on make clean:

...
/devel/fpc/3.2.2/bin/i386-Win32/rm.exe -f ./ppas.sh *_ppas.bat ppas.bat ppaslink.bat
make[2]: Leaving directory `C:/devel/fpc/trunk/rtl/win32' make[1]: Leaving directory `C:/devel/fpc/trunk/rtl' make -C utils distclean
make[1]: Entering directory `C:/devel/fpc/trunk/utils' { ./fpmake.exe distclean --localunitdir=.. --globalunitdir=../packages --os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o -di386 -o -dRELEASE --compiler=C:/devel/fpc/3.2.2/bin/i386-Win32/ppc386.exe -bu; if [ $? != "0" ]; then { echo Something wrong with fpmake exectable. Remove the executable and call make recursively to recover.; /devel/fpc/3.2.2/bin/i386-Win32/rm.exe -f ./fpmake.exe; make fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command, operable program or batch file.
make[1]: *** [distclean] Error 1
make[1]: Leaving directory `C:/devel/fpc/trunk/utils' make: *** [utils_distclean] Error 2

If I repeat this then the same error pops up later in some other folder.

That error goes away if I add C:\Windows to the path.

However, then I get the same build error:

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

(Even if I adjust the path to C:\devel\fpc\3.2.2\bin\i386-win32)

So, why then does fpc find the (wrong) common.dll in c:\windows\system32?

It seems I'm stuck with a machine with which I cannot build fpc anymore.

Looking with Windows Explorer at the Common.dll in question:

Productname: Intel(R) Extreme Tuning Utility
File version 7.3.0.33
Product version 7.3.0.33
Modified: 24-02-2021 (that's dd-mm-yyyy)

In the tab "Previos Version" it says: no previous version.

This must have been installed in some Windows update.

PM Bart wrote

Productname: Intel(R) Extreme Tuning Utility

And, of course, the guide on how to remove this utility (https://www.intel.com/content/www/us/en/support/articles/000032459/processors/processor-utilities-and-programs.html) do not apply.
No XtuService in "Apps and Features", no XtuService.exe. in any of the suggested locations.

The common.dll file itself cannot be moved, renamed, deleted or whatever.

On 64bit Windows system32 contains only 64 bit system files. syswow64 contains only 32 bit files and is seen as system32 for 32 bit apps. For some reason you have the 64 bit dll in the 32 bit syswow64 folder. You need to move this dll to the proper folder (system32).

Yuriy.

PM Yuriy Sydorov wrote

On 64bit Windows system32 contains only 64 bit system files. syswow64 contains only 32 bit files and is seen as system32 for 32 bit apps. For some reason you have the 64 bit dll in the 32 bit syswow64 folder. You need to move this dll to the proper folder (system32).

Easier said then done.
I can do nothing with that file. It's locked by the OS.

Also, won't that then give the same build error, but now with x86_64 (since obviously it is the wrong common.dll), because no matter with which %PATH% I try to build fpc, it WILL find the dll in c:\windows\system32.

Finally good news.

In taskmanager I had to stop one process,then go to services, find xtu3service.exe, right-click, then "open services", find that service again (now called XTUOCDriverService) in the newly opened window, right-click, select properties, then set Startup type (? "Opstart type") to Disabled.

After a reboot I was able to rename that common.dll to _common.dll, rebooted again.
All this as administrator of course.

Finally after all that I was able to build fpc for 32-bit.

And now just hoping that with the nex Windows update it won't get re-installed again.

 FPC finds the wrong library, because some stupid installer decided to place the 64-bit DLL in the 32-bit library folder which is simply *wrong*.

Regards,
Sven

Bart via fpc-devel schrieb am Di., 24.
Aug. 2021, 06:31:

Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then there would be no problem. However a 64-bit DLL in the SysWOW64 directory (thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit DLL in the System32 directory of a x86_64 system.

Regards,
Sven

PM Sven Barth wrote

Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then there would be no problem. However a 64-bit DLL in the SysWOW64 directory (thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit DLL in the System32 directory of a x86_64 system.

Even if the dll does not match the description/specs in the source code? (Just curious)

And, being curious: any idea why make clean failed when %PATH% was set to just C:\fpc\3.2.2\bin\i386-win32 ?

No idea - I just tested on a MS Win machine I have access to and 'make clean all' succeeded with PATH containing just the bin\i386-win32 subdirectory of the 3.2.2 installation. Do you have a complete FPC installation, or did you build 3.2.2 yourself?

Tomas

I have a complete fpc install (official installer). Looking at the error message, it looks like at some point it the shell (cmd.exe) is instructed to execute code that one would expect in a linux bash script. (Except that it has a reference to fpmake.exe, which doesn't sound very *nix)

make -C utils distclean
make[1]: Entering directory `C:/devel/fpc/trunk/utils' { ./fpmake.exe distclean --localunitdir=.. --globalunitdir=../packages --os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o -di386 -o -dRELEASE --compiler=C:/devel/fpc/3.2.2/bin/i386-Win32/ppc386.exe -bu; if [ $? != "0" ]; then { echo Something wrong with fpmake exectable. Remove the executable and call make recursively to recover.; /devel/fpc/3.2.2/bin/i386-Win32/rm.exe -f ./fpmake.exe; make fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command, operable program or batch file.

Thanks for this description which I found now 19 months later!

I had trouble installing the Win32 version of Lazarus/Fpc using fpcupdeluxe, because I wanted a cross-compile tool for RaspberryPi on my Windows10 x64 box. But the install failed no matter what I did with an error message that was hard to decode for me.

Now I have done the following as described above:

-Started Servicemanager on my Win10 workstation.

- Found the Intel service "XTUOCDriverService" and stopped it

- Then I also set the type to disabled.

- But I did not reboot, instead I renamed the common.dll in C:\Windows\SysWOW64 to _common.dll, which was allowed now.

- Then I just started the fpcupdeluxe 32 bit exe and commanded it to install 3.2.2/Lazarus 2.2.6. And this time it succeeded!

- So when it was done I could tell fpcupdeluxe to install the cross-compiler for arm-linux, which it also successfully completed.

The base install took 19m30s and the cross another 5 minutes when it fetched the various source files from the Internet.