<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi All!<br>
<br>
After a multi-day debugging binge, I found the problem described in
my previous email.<br>
<br>
Quick summary:<br>
<br>
Common Library has a unit which defines a generic class that itself
is derived from a class from another unit of the same library.<br>
<br>
Application Library has many units which specialize the generic
class.<br>
<br>
Compiling the Application LIbrary causes a "File not found" error
giving the name of a valid file (the one declaring the generic) but
in an incorrect directory, There is no indication of where the
failure (<a class="moz-txt-link-freetext" href="file:line">file:line</a> no) occurs. There is no sign of the file where
the error message says it is (that part is correct, but why it
happens is not).<br>
<br>
A long series of tests determined that the error occurs in all files
that specialize the generic class. I had not touched the file
declaring the generic class in years.<br>
<br>
The bug in my code was in the Common Library unit that declared the
class from which the generic class was derived. FPC 3.0.0 did not
detect the following error in the class declaration:<br>
<br>
<tt> class function Load( TextIO : TTextIO; aParent : TPersists =
nil ) : TPersists; virtual; overload; // Calls read afterwards<br>
<br>
procedure Load( TextIO : TTextIO ); overload; // Loads without
creating <b><<< this was newly added and caused the p</b><b>roblem.
fpc did not object!<br>
<br>
</b></tt>This module is many years old. I know now that the class
function could have been replaced by a constructor, but that would
require refactoring many working programs. <br>
<br>
I added the procedure recently to simplify a lot of application code
(which it did). It had been working without the error for a few
days. I don't know what I did to trigger the failure, but once I
did it would not go away (that in itself is problematic, I would
have expected the failure right after I introduced the bug).<br>
<br>
The first instance of the error occurred using Lazarus 1.7/fpc 3.0.0
on Raspbian. During the bug hunt, I copied the code to my laptop
where it occurred using Lazarus 1.6RC2/fpc 3.0.0 on Linux Mint 17.3.<br>
<br>
When I changed the code to:<br>
<br>
<tt><tt> class function Load( TextIO : TTextIO; aParent :
TPersists = nil ) : TPersists; virtual; // Calls read afterwards<br>
<br>
</tt> procedure LoadExisting( TextIO : TTextIO ); // Loads
without creating <br>
<br>
</tt>and refactored, the errors disappeared and the recursion tests
worked.<br>
<br>
I believe this is a Compiler bug so I will post a bug report for fpc
over the weekend.<br>
<br>
Comments will be appreciated.<br>
<br>
Don Ziesig<br>
<tt><br>
</tt><tt></tt><br>
</body>
</html>