I've been using 1.0.6 for about 2 years now. It's always served me well (thanks guys!), which is precisely why I've been reluctant to upgrade. The only things I develop any more are console-mode, 32 bit Windows programs, so a lot of the new features didn't pertain to me. However, the other day I downloaded a copy of 1.9.4 to give it a try. I used pkzip to archive my entire 1.0.6 installation. Then I deleted those old files and installed the new version.

Unfortunately, while trying to compile some of my units and programs with 1.9.4 it became apparent that there were more changes in the past 2 years then I thought because I was getting a lot of warnings and errors I had never gotten before (some of my stuff has been compiling, and working, for years now, so I'm fairly confident the code is okay).

Seeing as how it was going to take a lot of coding -- and documentation reading -- to find out what was going wrong I decided to wait for another day, when I could actually devote the necessary time to do it properly. So I deleted 1.9.4 and restored my zip of 1.0.6. But now it doesn't work. :-(

Every time I try compiling something I get the error "Fatal: Can't find unit SYSWIN32". syswin32.ow and syswin32.ppw are both in c:\fpc\units\win32\rtl, so that's not the problem. fpc.cfg has the following lines:

-Fuc:\fpc/units/$TARGET
-Fuc:\fpc/units/$TARGET/*
-Fuc:\fpc/units/$TARGET/rtl

So that's not the problem either. The Compile.bat I use hasn't been modified in at least a year, so even that's not an issue. I use the command line "ppc386 -OG -n -vehnw -WC -Xs -XX", which isn't all that complex either.

Since everything looks fine -- and it's what I've been using, unmodified, for the better part of 2 years -- I'm pretty certain my config is okay. I thought that maybe the .zip was corrupted, but according to pkzip (version
4) it checks out fine. I even went as far as removing that version and trying to unzip it again, but the same problem keeps happening.

Okay, after this loooong winded story the question is; what am I missing? This is the EXACT same setup I've been using for a very long time, but for some reason it's not working now. Does anyone have an idea of what's going wrong here?

TIA...

Regards,
Jim Wilson

Maybe the stuff worked because of other bugs in 1.0.6. The error messages are not added for fun to let ppl review their code. Most are there because the compiler can't continue or will generate wrong code. And the warnings will only help in finding bugs.

Add -vt to see where ppc386 looks for the files.

you wrote

Maybe the stuff worked because of other bugs in 1.0.6. The error messages are not added for fun to let ppl review their code. Most are there because the compiler can't continue or will generate wrong code. And the warnings will only help in finding bugs.

I wasn't criticizing anyone, only trying to relay the whole story (and part of the story is that I was only reverting back to an older version because the newer one was going to require more effort then I had time for at that moment).

Add -vt to see where ppc386 looks for the files.

Alright, this proved to be very beneficial! It told me where fpc was looking for the units, but I can't for the life of me figure out WHY it's looking there. Here's what -vt gave me the first time around:

BEFORE
Compiler: c:\fpc\bin\win32\ppc386.exe
Using executable path: c:\fpc\bin\win32\
Using unit path: c:\source\
Using library path: c:\source\
Using object path: c:\source\
Unitsearch: syswin32.ppw
Unitsearch: \fpc\compiled\syswin32.ppw
Unitsearch: syswin32.pp
Unitsearch: syswin32.pas
Unitsearch: c:\source\syswin32.ppw
Unitsearch: c:\source\syswin32.pp
Unitsearch: c:\source\syswin32.pas
si.pas(56,1) Fatal: Can't find unit SYSWIN32

When I added "-Fuc:\fpc\units\win32\rtl" (with or without "-n" too) directly to my command line I got this:

AFTER
Compiler: c:\fpc\bin\win32\ppc386.exe
Using executable path: c:\fpc\bin\win32\
Using unit path: c:\source\
Using unit path: c:\fpc\units\win32\rtl\
Using library path: c:\source\
Using library path: c:\fpc\units\win32\rtl\
Using object path: c:\source\
Using object path: c:\fpc\units\win32\rtl\
Unitsearch: syswin32.ppw
Unitsearch: \fpc\compiled\syswin32.ppw
Unitsearch: syswin32.pp
Unitsearch: syswin32.pas
Unitsearch: c:\source\syswin32.ppw
Unitsearch: c:\source\syswin32.pp
Unitsearch: c:\source\syswin32.pas
Unitsearch: c:\fpc\units\win32\rtl\syswin32.ppw
PPU Loading c:\fpc\units\win32\rtl\syswin32.ppw
Unitsearch: c:\fpc\units\win32\rtl\syswin32.pp
Unitsearch: c:\fpc\units\win32\rtl\syswin32.pas
si.pas(56,1) Fatal: Can't find unit SYSWIN32

It seems to be looking in the correct spot now, and syswin32.ppw does indeed exist in the \fpc\units\win32\rtl directory, but it's still giving me the same error (and I'm assuming the message "PPU Loading" means it found the unit and loaded it, which would make it all the more confusing).

Regards,
Jim Wilson

Use -vu to see the reason why it wants to recompile the unit

you wrote

Use -vu to see the reason why it wants to recompile the unit

Okay, -vu give me this:

Load from SI (implementation) unit SYSWIN32
PPU Name: c:\fpc\units\win32\rtl\syswin32.ppw
PPU Time: 2004/06/22 23:20:38
PPU Flags: 12497
PPU Crc: 375220168
PPU Crc: 71143866 (intfc)
PPU Check file c:\fpc\units\win32\rtl\libpsyswin32.aw time 2004/06/22 23:20:36 Recompiling unit, static lib is older than ppufile si.pas(56,1) Fatal: Can't find unit SYSWIN32

From that output I was able to determine the problem. And do you know what that problem was? Seems as though pkzip changed the dates on the unzipped files, and this was somehow screwing up FPC. Once I reset the dates on all the files in the FPC directory to the same date the compiler returned with -iD everything started working again!

So I think I'm all set. Thanks for the help...

Regards,
Jim Wilson