Linking new user code unit to library of precompiled ppu/o/lfm

[fdsingleton]

This problem is too complex to really post code.  When using pre-3.0.0 FPC & Lazarus I was able to get around it several years ago, but am at a loss to update to 3.0.0.  There are about 20 proprietary units, with 2 threads defined in addition to the Windows original thread. 
It was originally developed with (ancient) Delphi 3 and still works with it.  After creating the standard library of about 20 units, when I try to link them with a new user unit (of rigidly standard format and fixed interface, no gui form) I may get a message such as

PPU Loading C:\MyP\DMS\units\Dmsdefs.ppu
PPU Source: DMSDEFS.pas not found
Recompiling DMSDEFS, checksum changed for DMSPROCS
DUnit1.pas(113,11) Fatal: Can't find unit DMSDEFS used by DUnit1
Fatal: Compilation aborted
Error: E:\FPC\lazarus\fpc\3.0.0\bin\i386-win32\ppc386.exe returned an error exit
code

DMSDEFS.PAS and DUnit1.pas are part of the standard code which I do not give to the end user.
I don't want to have to give the user my thousands of lines of proprietary standard code developed over the last 20 years just to get a link.   One time I was able to get a successful link by using -Ur, (I think---I never have continuous time to work on this), the program went thru its paces, but the numerical results were garbage.  Does anyone have any suggestions?

[Handoko]

Have you tried Delphi Conversion tools?
Lazarus main menu > Tools > Delphi Conversion.

Can't find file problem may happen if you do not set the search path properly.
Lazarus main menu > Project > Project Options > Paths.

More information, read these:
http://wiki.freepascal.org/Unit_not_found_-_How_to_find_units
http://wiki.freepascal.org/Delphi_Converter_in_Lazarus

[fdsingleton]

Originally the program was converted using a Delphi converter for a previous version FPC.  Some changes have occurred since then.  The program works fine if you just compile the whole thing from scratch in Lazarus.   It is a simultaneous system solver with possible ordinary differential equation integration, and the end-user unit implementation part contains the user equation code.

 The point is, the source code that the compiler demands would not be given to the end user.  I need to link release versions of all the ppu's and o's with the end-user unit which only has changes in its implementation part---but FPC demands to recompile more source code than has been changed.  Delphi 3 has never done this.  Somehow I got around this previously with FPC but have not been able to do it with 3.0.0.

[Jonas Maebe]

After creating the standard library of about 20 units, when I try to link them with a new user unit (of rigidly standard format and fixed interface, no gui form) I may get a message such as

PPU Loading C:\MyP\DMS\units\Dmsdefs.ppu
PPU Source: DMSDEFS.pas not found
Recompiling DMSDEFS, checksum changed for DMSPROCS
DUnit1.pas(113,11) Fatal: Can't find unit DMSDEFS used by DUnit1
Fatal: Compilation aborted
Error: E:\FPC\lazarus\fpc\3.0.0\bin\i386-win32\ppc386.exe returned an error exit
code

This is probably caused by declaring routines normally in the interface of DMSPROCS, and then redeclaring them as external in the implementation. If that is the case, declare them directly as external in the interface. The reason this causes a recompilation is because implementation "external" definition changes the interface definition of the routine, which in turn causes the CRC of the interface to change. If you use units in the implementation section of DMSPROCS that in turn also depend on DMSPROCS, they may have been compiled against the original interface and hence stored the original CRC (which will be checked during subsequent compilations to determine whether they need to be recompiled).

An alternative workaround is to compile the units twice on your own system (without deleting the result of the first compile). Since you have the source code, this second compilation will succeed on your system. DMSPROCS won't be recompiled during the second compilation (unless it also depends on a unit using such constructs, in which case you might have to compile everything a third time), so units depending on DMSPROCS will now store its final CRC instead.

DMSDEFS.PAS and DUnit1.pas are part of the standard code which I do not give to the end user.
I don't want to have to give the user my thousands of lines of proprietary standard code developed over the last 20 years just to get a link.   One time I was able to get a successful link by using -Ur, (I think---I never have continuous time to work on this), the program went thru its paces, but the numerical results were garbage.  Does anyone have any suggestions?

-Ur is indeed the usual way to prevent the compiler from wanting to recompile units, although I'm not 100% sure it will also help with interface checksum changes. -Ur does not affect numerical results in any way. It only tells the compiler that if it finds source files used in the compilation of a unit with a newer time stamp than what was originally used, it should not try to recompile the unit.

[fdsingleton]

Thanks very much for the info.  I think the way I got things to work with the previous version of FPC involved something like compiling twice.  However, this time it did not work and the error messages I posted were from the 2nd try --- it just wanted another unit source as stated in the error message.  Probably a stupid question--- I don't think the word "external" appears after any procedure heading or anywhere in the code, so how does something become external?  I will try to read up on this.  It would be nice to rid the system of this problem.

[Jonas Maebe]

Thanks very much for the info.  I think the way I got things to work with the previous version of FPC involved something like compiling twice.  However, this time it did not work and the error messages I posted were from the 2nd try --- it just wanted another unit source as stated in the error message.

I don't understand. You have all sources on your system, so compiling the second time should work there.

Probably a stupid question--- I don't think the word "external" appears after any procedure heading or anywhere in the code, so how does something become external?

The only way something can become external is indeed with an "external" declaration. Another possible case is with inline routines.

In current FPC trunk, I think we got rid of all cases that could cause the interface crc to change during the compilation of the implementation, but those changes won't make it into 3.0.x.