Hi,

I tried to fix the OS/2 main branch snapshot problems last week, but with no success. The compilation process stops at the RTL, at sysutils.pp AFAIR, by saying there are some declarations not compatible with their forward declarations... Anyway, i looked through the problem sources, and found no sign of any forward declaration for the problematic procedures... I tried to switch back to older 1.1, then to 1.0.x, but with no success. Anyway i had not much time to play with, so it remained a mystery to me.

Is it working for others? If not, anyone can take a look at it please?

Other:

The Linux PPC RTL compilation is broken too, while compiling system.pp i get:
/usr/bin/ppcppc -Ur -Xs -n -Fi../inc -Fi../powerpc -Fi../unix -Fe. -dpowerpc -dRELEASE -Us -Sg system.pp
system.pp(35,2) Fatal: Can't open include file "sysunixh.inc"

I'm using the PPC version Jonas gave me as base (dated 2003/06/02).

The interresting part from fpcdebug.txt (used make rtl OPT=-V)

00020000:interpreting option "-Fi../powerpc"
00000020:Path "/powerpc/" not found

... and so with all other -Fi parameters (unix, inc).

I just tried a recent snapshot on a Linux/x86 box, and there is no such problem.

Bye,

Hi,

I just cross-compiled a new PPC compiler & rtl, using yesterday's Linux/x86 snapshot compiler as the base, and using the latest CVS sources, but the problem is still there.

Bye,

Then I think your CVS is rotten. Try to cycle with -va, and see if there are files marked with an asterisk, or "recompiling unit" lines.

Try to clean linux/ manually.

Hi,

I don't think it's a problem of my CVS, just look at the part of my first message, where i quote a part of the fpcdebug.txt... the -Fi include paths got messed up complettely.

Anyway i deleted the whole rtl directory, and checked out again, but nothing changed.

-- While the nightly ppc build failed for some vague reasons that I've hopefully fixed, I ran it manually, and put the generated (CVS 15-07-2003 +/- 21:00 CET) compiler on http://www.stack.nl/~marcov/ppcppc.bz2

The compiler builds here too, but only the RTL compilation fails. I tried with your compiler now, and the result is the same.

Bye,

Could you build with -va and post the result somewhere, or mail it to me?

It's indeed an odd case, and not what I expected. The problem seems to be in the partialy path expansion, which could also explain why it worked in my case and not in your case (differences in dir structure, symlinks or random garbadge in "empty" direntries).

Handling option "-Fi../inc"
interpreting option "-Fi../inc"
Hint: Path "/inc/" not found
Handling option "-Fi../powerpc"
interpreting option "-Fi../powerpc"
Hint: Path "/powerpc/" not found
Handling option "-Fi../unix"
interpreting option "-Fi../unix"
Hint: Path "/unix/" not found
Handling option "-Fipowerpc"
interpreting option "-Fipowerpc"
Hint: Path "/powerpc/" not found

If it where my machine, my next step would be to look at the syscalls (strace) to see if I could find something strange there. Anyway, in both cases it involves single stepping the compiler. (probably putting a breakpoint in sysunix.inc, and stepping from there)

Afaik that binary from me _had_ debugging info, so you could do that. (but I don't know if you have done that before?)

Hi,

Marco van de Voort wrote

> The compiler builds here too, but only the RTL compilation fails. > I tried with your compiler now, and the result is the same. Could you build with -va and post the result somewhere, or mail it to me?

Since it's not too big, i attached here.

This is the result, when i give out make OPT=-va from /rtl/linux. The compiler i used this time was the one from the URL in your previous mail.

The Linux i use is a DebianPPC 3.0r1, on a 604e/200 PowerMac8500, with kernel 2.4.21-ben2, but i don't think this makes any sense.

Bye,

Karoly wrote

I just cross-compiled a new PPC compiler & rtl, using yesterday's Linux/x86 snapshot compiler as the base, and using the latest CVS sources, but the problem is still there.

Try doing a "cvs up -Pd", that will delete files which have been deleted from CVS (and add directories whch have been added in CVS).

Jonas

Karoly wrote

The Linux i use is a DebianPPC 3.0r1, on a 604e/200 PowerMac8500, with kernel 2.4.21-ben2, but i don't think this makes any sense.

I think I encountered this bug already in the beginning of doing the PowerPC port, but I don't remember anymore what the cause was :/

Jonas

Hi,

Jonas Maebe wrote

> The Linux i use is a DebianPPC 3.0r1, on a 604e/200 PowerMac8500, > with kernel 2.4.21-ben2, but i don't think this makes any sense. I think I encountered this bug already in the beginning of doing the PowerPC port, but I don't remember anymore what the cause was :/

I tracked down the problem until the FExpand() call of the DOS library. Instead of the full pathname, it always returns '/<filename>', so for example FExpand('bug.pas') returns /bug.pas, while bug.pas is at the directory of the executable.

Example:
program bug;
uses DOS;
const BugStr = 'bug.pas';
var FExResult : PathStr;
begin
 FExResult:=FExpand(BugStr);
 WriteLn(FExResult);
end.

On my PowerPC Linux it returns:
./bug
/bug.pas

(AFAIK should return /home/charlie/fpcbug/bug.pas)

Bye,

Indeed. Here it returns "/gentoo/pp/bug.pas" ... If you want to debug it further and don't feel like using plain gdb, I've put a copy of gdbpas for linuxppc at
<http://jonagold.elis.ugent.be:8080/~jonas/fpc/gdbpas.bz2> (2.6MB, compiled by Marco). I think the problem is in GetDir, as that one is used to get the current directory.

Jonas

From: "Balogh, Karoly (Charlie/iNQ)"

To:
Subject: [fpc-devel]CVS compilation problems. Send reply to:

Date sent: Tue, 15 Jul 2003 18:18:24 +0200

Hi,

I tried to fix the OS/2 main branch snapshot problems last week, but with no success. The compilation process stops at the RTL, at sysutils.pp AFAIR, by saying there are some declarations not

OS/2 main branch compilation works well for me now (it's quite some time since your report, so I don't know, whether your problem was somewhere in the compiler and somebody fixed it in between). I had to create a new 1.1.x compiler using 1.0.x first, though, because the older 1.1 compiler didn't work for some reason. The only trouble I had was a bug in unzipdll.pp (not detected with 1.0.x), but this one was easy to fix.

Tomas

From: "Balogh, Karoly (Charlie/iNQ)"

To:
Subject: [fpc-devel]Re: CVS compilation problems. Send reply to: <mailto:fpc-devel-

<mailto:fpc-devel-

Date sent: Sun, 20 Jul 2003 01:01:41 +0200

Hi Charlie,

.
.

Sorry for not replying till now, I'm "little bit" behind with reading the lists because of holidays. :-( What does "GetDir (0, S); WriteLn (S);" return for you on that machine?

Tomas

Hi,

./test
/home/charlie/bugtest

This is with the ppcppc binary & RTL by Jonas, dated 2003/06/02. The very same compiler refuses to compile a snapshot, because of path problems described before. Same with the compiler and rtl compiled 'by hand', dated 2003/07/17. Also with a compiler cross-compiled from x86. Will try to build a recent compiler and RTL soon, and see if anything was changed since then...

Bye,

Note that -Or is currently broken for ppc.

Jonas

From: "Balogh, Karoly (Charlie/iNQ)"
To:

Subject: [fpc-devel]Re: CVS compilation problems. Date: Wed, 3 Sep 2003 0:29:27 +0200

Hi,

.
.

from x86. Will try to build a recent compiler and RTL soon, and see if anything was changed since then...

If it still fails, please, compile
/tests/test/units/dos/tfexpand.pp from CVS with -dDEBUG (or remove the space on line 5 of that file) as well, and send me redirected output of that one.

Thanks

Tomas

Hi,

If it still fails,

The current RTL building fails with the 0602 compiler by Jonas with internal error 200107271 in math.inc...

please, compile /tests/test/units/dos/tfexpand.pp from CVS with -dDEBUG (or remove the space on line 5 of that file) as well, and send me redirected output of that one.

Here is the log generated by tfexpand.pp compiled with the 2003/06/02 compiler. I'll cross-compile a new compiler from x86, but currently i don't have time for that... :/

Anyway, the EMX snapshot broke again, because the CVS version of classes.pp failed to merge correctly with my patched version on the building machine, so it doesn't compile now... :((( Will fix it tomorrow. (I hope.)

Bye,

From: "Balogh, Karoly (Charlie/iNQ)"
To:

Subject: [fpc-devel]Re: CVS compilation problems. Date sent: Wed, 3 Sep 2003 14:59:58 +0200

The FExpand test passed without any problems! Could you have a look at your original problem (I mean the original parameters passed to FExpand which supposedly caused incorrect results) and try to find out whether there's something different from the examples tested in tfexpand.pp? You were calling FExpand with '.' in your original test, weren't you (I'm still in my office and don't have your original mail here)?

Yes, this was to be expected actually if you kept your changes there. You should probably just delete your version.

Tomas

Probably a bug related to an uninitialised valriable (not necessarily in the Pascal code, it's possible that it's a bug in the ppc code causes this initialisation not to happen)

Jonas

Hi,

The FExpand test passed without any problems!

Hmmm... Something mysterious is happening here. The _SAME_ executable (compiled on 2003/07/20) which returned /bug.pas now returns the expected /home/charlie/fpcbug/bug.pas!

I really don't have any explanations. Black magic... 8/

Bye,