[fpc-devel] Strange build error
On Win7 I encounter the following fatal error on make clean all of trunk (19693): D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe -f ./pp.exe ppc386.exe D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe: cannot remove `ppc386.exe': Permission denied There exists a pp.exe in the current (compiler) directory, as just built, but no ppc386.exe. The path however is set to the above 2.4.2 bin directory, where such a file resides. I cannot remember such a problem with older revisions. Any clues? Building with fpc 2.5.1 stops before that point, with Generics... errors in fgl.pp. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange build error
Am 27.11.2011 10:43, schrieb Hans-Peter Diettrich: On Win7 I encounter the following fatal error on make clean all of trunk (19693): D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe -f ./pp.exe ppc386.exe D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe: cannot remove `ppc386.exe': Permission denied There exists a pp.exe in the current (compiler) directory, as just built, but no ppc386.exe. The path however is set to the above 2.4.2 bin directory, where such a file resides. I cannot remember such a problem with older revisions. Any clues? Anti virus? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
27.11.2011 0:41, Leonardo M. Ramé пишет: This is the output I get after update: ... Well, now ppc2.exe at least starts. Can you further try to build with OPT=-dDISABLE_TLS_DIRECTORY ? But don't execute 'make clean all OPT=-dDISABLE_TLS_DIRECTORY' at the top-level directory, as in this case OPT is apparently ignored. Instead, change dir to 'e:\fpc\compiler' and execute make cycle OPT=-dDISABLE_TLS_DIRECTORY Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
On 27 Nov 2011, at 12:05, Sergei Gorelkin wrote: But don't execute 'make clean all OPT=-dDISABLE_TLS_DIRECTORY' at the top-level directory, as in this case OPT is apparently ignored. I regularly use OPT at the top level myself and I've never seen it being ignored in that situation. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
27.11.2011 13:09, Jonas Maebe пишет: On 27 Nov 2011, at 12:05, Sergei Gorelkin wrote: But don't execute 'make clean all OPT=-dDISABLE_TLS_DIRECTORY' at the top-level directory, as in this case OPT is apparently ignored. I regularly use OPT at the top level myself and I've never seen it being ignored in that situation. Earlier in this thread Leonardo wrote: Sven, I added OPT=-gl but I got exactly the same output. I also tried with clean all OPT=-gl and got the same. From this I concluded that something goes wrong with OPT at top level at least in this particular case. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
On 27 Nov 2011, at 12:19, Sergei Gorelkin wrote: 27.11.2011 13:09, Jonas Maebe пишет: I regularly use OPT at the top level myself and I've never seen it being ignored in that situation. Earlier in this thread Leonardo wrote: Sven, I added OPT=-gl but I got exactly the same output. I also tried with clean all OPT=-gl and got the same. From this I concluded that something goes wrong with OPT at top level at least in this particular case. It can also mean that the code in the lineinfo unit didn't work for some reason, which seems more likely to me. Even the -Xs added by the top level make all doesn't cause problems in that case, because the OPT parameters are added at the end of the command line and -g will disable -Xs if it comes after it. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
27.11.2011 13:26, Jonas Maebe пишет: On 27 Nov 2011, at 12:19, Sergei Gorelkin wrote: 27.11.2011 13:09, Jonas Maebe пишет: I regularly use OPT at the top level myself and I've never seen it being ignored in that situation. Earlier in this thread Leonardo wrote: Sven, I added OPT=-gl but I got exactly the same output. I also tried with clean all OPT=-gl and got the same. From this I concluded that something goes wrong with OPT at top level at least in this particular case. It can also mean that the code in the lineinfo unit didn't work for some reason, which seems more likely to me. Even the -Xs added by the top level make all doesn't cause problems in that case, because the OPT parameters are added at the end of the command line and -g will disable -Xs if it comes after it. After re-testing and seeing that OPT is indeed passed correctly, I agree that I had made a wrong conclusion here. But let's wait for feedback; if compiler alone can be cycled with DISABLE_TLS_DIRECTORY then the whole trunk is very probably can build that way too. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange build error
Florian Klämpfl schrieb: Anti virus? This was my first guess as well, but deactivating online-scanning didn't help. So I uninstalled BitDefender completely, and now it worked :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
- Original Message - From: Sergei Gorelkin sergei_gorel...@mail.ru To: fpc-devel@lists.freepascal.org Cc: Sent: Sunday, November 27, 2011 9:07 AM Subject: Re: [fpc-devel] Building trunk on Win32 27.11.2011 13:26, Jonas Maebe пишет: On 27 Nov 2011, at 12:19, Sergei Gorelkin wrote: 27.11.2011 13:09, Jonas Maebe пишет: I regularly use OPT at the top level myself and I've never seen it being ignored in that situation. Earlier in this thread Leonardo wrote: Sven, I added OPT=-gl but I got exactly the same output. I also tried with clean all OPT=-gl and got the same. From this I concluded that something goes wrong with OPT at top level at least in this particular case. It can also mean that the code in the lineinfo unit didn't work for some reason, which seems more likely to me. Even the -Xs added by the top level make all doesn't cause problems in that case, because the OPT parameters are added at the end of the command line and -g will disable -Xs if it comes after it. After re-testing and seeing that OPT is indeed passed correctly, I agree that I had made a wrong conclusion here. But let's wait for feedback; if compiler alone can be cycled with DISABLE_TLS_DIRECTORY then the whole trunk is very probably can build that way too. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Well, I found I had an e:\pp directory containing an fpc 2.5.1, and my PATH was pointing to it, so my previous tests could have been influenced by some files from that directory. After deleting it, I compiled from top level directory using: e:\fpc-bin\bin\i386-win32\make clean OPT=-dDISABLE_TLS_DIRECTORY all PP=e:\fpc-bin\bin\i386-win32\ppc386.exe and it worked without issues. Then, I did e:\fpc-bin\bin\i386-win32\make clean all PP=e:\fpc-bin\bin\i386-win32\ppc386.exe and got this: ... win32/libimpvarutils.a E:/fpc/rtl/units/i386-win32/libimpsharemem.a E:/fpc/rtl/units/i386-win32/libimpfpintres.a e:/FPC-bin/bin/i386-Win32/rm.exe -f E:/fpc/rtl/units/i386-win32/math.rst E:/fpc/rtl/units/i386-win32/varutils.rst E:/fpc/rtl/units/i386-win32/typinfo.rst E:/fpc/rtl/units/i386-win32/variants.rst E:/fpc/rtl/units/i386-win32/classes.rst E:/fpc/rtl/units/i386-win32/dateutils.rst E:/fpc/rtl/units/i386-win32/sysconst.rst e:/FPC-bin/bin/i386-Win32/rm.exe -f fpcmade.i386-win32 Package.fpc ppas.bat script.res link.res e:/FPC-bin/bin/i386-Win32/rm.exe -f *.s *_ppas.bat make[7]: Leaving directory `E:/fpc/rtl/win32' make[6]: Leaving directory `E:/fpc/rtl' e:/fpc-bin/bin/i386-win32/make -C E:/fpc/rtl 'OPT=' all make[6]: Entering directory `E:/fpc/rtl' e:/fpc-bin/bin/i386-win32/make -C win32 all make[7]: Entering directory `E:/fpc/rtl/win32' E:/fpc/compiler/ppc2.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUE:/fpc/rtl/units/i386-win32 -di386 -dRELEASE -Us -Sg system.pp -Fi../win make[7]: *** [system.ppu] Error 255 make[7]: Leaving directory `E:/fpc/rtl/win32' make[6]: *** [win32_all] Error 2 make[6]: Leaving directory `E:/fpc/rtl' make[5]: *** [rtl] Error 2 make[5]: Leaving directory `E:/fpc/compiler' make[4]: *** [next] Error 2 make[4]: Leaving directory `E:/fpc/compiler' make[3]: *** [ppc3.exe] Error 2 make[3]: Leaving directory `E:/fpc/compiler' make[2]: *** [cycle] Error 2 make[2]: Leaving directory `E:/fpc/compiler' make[1]: *** [compiler_cycle] Error 2 make[1]: Leaving directory `E:/fpc' e:\fpc-bin\bin\i386-win32\make: *** [build-stamp.i386-win32] Error 2 Conclussion, the DISABLE_TLS_DIRECTORY worked as expected. -- Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
27.11.2011 16:45, Leonardo M. Ramé пишет: Well, I found I had an e:\pp directory containing an fpc 2.5.1, and my PATH was pointing to it, so my previous tests could have been influenced by some files from that directory. After deleting it, I compiled from top level directory using: e:\fpc-bin\bin\i386-win32\make clean OPT=-dDISABLE_TLS_DIRECTORY all PP=e:\fpc-bin\bin\i386-win32\ppc386.exe and it worked without issues. Good. Even better is that we didn't enable these TLS callbacks for 2.6 :-/ Then, I did e:\fpc-bin\bin\i386-win32\make clean all PP=e:\fpc-bin\bin\i386-win32\ppc386.exe and got this: ... win32/libimpvarutils.a E:/fpc/rtl/units/i386-win32/libimpsharemem.a E:/fpc/rtl/units/i386-win32/libimpfpintres.a e:/FPC-bin/bin/i386-Win32/rm.exe -f E:/fpc/rtl/units/i386-win32/math.rst E:/fpc/rtl/units/i386-win32/varutils.rst E:/fpc/rtl/units/i386-win32/typinfo.rst E:/fpc/rtl/units/i386-win32/variants.rst E:/fpc/rtl/units/i386-win32/classes.rst E:/fpc/rtl/units/i386-win32/dateutils.rst E:/fpc/rtl/units/i386-win32/sysconst.rst e:/FPC-bin/bin/i386-Win32/rm.exe -f fpcmade.i386-win32 Package.fpc ppas.bat script.res link.res e:/FPC-bin/bin/i386-Win32/rm.exe -f *.s *_ppas.bat make[7]: Leaving directory `E:/fpc/rtl/win32' make[6]: Leaving directory `E:/fpc/rtl' e:/fpc-bin/bin/i386-win32/make -C E:/fpc/rtl 'OPT=' all make[6]: Entering directory `E:/fpc/rtl' e:/fpc-bin/bin/i386-win32/make -C win32 all make[7]: Entering directory `E:/fpc/rtl/win32' E:/fpc/compiler/ppc2.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUE:/fpc/rtl/units/i386-win32 -di386 -dRELEASE -Us -Sg system.pp -Fi../win make[7]: *** [system.ppu] Error 255 make[7]: Leaving directory `E:/fpc/rtl/win32' make[6]: *** [win32_all] Error 2 make[6]: Leaving directory `E:/fpc/rtl' make[5]: *** [rtl] Error 2 make[5]: Leaving directory `E:/fpc/compiler' make[4]: *** [next] Error 2 make[4]: Leaving directory `E:/fpc/compiler' make[3]: *** [ppc3.exe] Error 2 make[3]: Leaving directory `E:/fpc/compiler' make[2]: *** [cycle] Error 2 make[2]: Leaving directory `E:/fpc/compiler' make[1]: *** [compiler_cycle] Error 2 make[1]: Leaving directory `E:/fpc' e:\fpc-bin\bin\i386-win32\make: *** [build-stamp.i386-win32] Error 2 Conclussion, the DISABLE_TLS_DIRECTORY worked as expected. The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise suggests that the foreign thread raises exceptions and FPC tries to handle them. Error 255 is most likely caused by Halt(255) in rtl/inc/except.inc line 200 or 303, these are the only places where RTL can exit with code 255. This is explainable: FPC won't have ExceptObjectStack or ExceptAddressStack set up for the foreign thread, they will contain nil values. But I don't imagine how it manages to work *without* TLS callbacks. The difference is that RTL will remain in single-threaded mode, but SetUnhandledExceptionFilter that is used to intercept exceptions is AFAIK global and will still break in. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
On 27.11.2011 16:45, Sergei Gorelkin wrote: The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise suggests that the foreign thread raises exceptions and FPC tries to handle them. Error 255 is most likely caused by Halt(255) in rtl/inc/except.inc line 200 or 303, these are the only places where RTL can exit with code 255. This is explainable: FPC won't have ExceptObjectStack or ExceptAddressStack set up for the foreign thread, they will contain nil values. But I don't imagine how it manages to work *without* TLS callbacks. The difference is that RTL will remain in single-threaded mode, but SetUnhandledExceptionFilter that is used to intercept exceptions is AFAIK global and will still break in. Also interesting question: why does so far only Leonardo experience that problem? I myself have no problem building trunk on a Windows 7 machine using 2.4.4 as a starting compiler. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange build error
On 27.11.2011 14:31, Hans-Peter Diettrich wrote: Florian Klämpfl schrieb: Anti virus? This was my first guess as well, but deactivating online-scanning didn't help. So I uninstalled BitDefender completely, and now it worked :-) It's fascinating how much can be broken by an anti virus program -.- Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
- Original Message - From: Sven Barth pascaldra...@googlemail.com To: fpc-devel@lists.freepascal.org Cc: Sent: Sunday, November 27, 2011 1:10 PM Subject: Re: [fpc-devel] Building trunk on Win32 On 27.11.2011 16:45, Sergei Gorelkin wrote: The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise suggests that the foreign thread raises exceptions and FPC tries to handle them. Error 255 is most likely caused by Halt(255) in rtl/inc/except.inc line 200 or 303, these are the only places where RTL can exit with code 255. This is explainable: FPC won't have ExceptObjectStack or ExceptAddressStack set up for the foreign thread, they will contain nil values. But I don't imagine how it manages to work *without* TLS callbacks. The difference is that RTL will remain in single-threaded mode, but SetUnhandledExceptionFilter that is used to intercept exceptions is AFAIK global and will still break in. Also interesting question: why does so far only Leonardo experience that problem? I myself have no problem building trunk on a Windows 7 machine using 2.4.4 as a starting compiler. Regards, Sven Maybe because of my setup: Win2003 32bits (and its updates) running on a VirtualBox machine that hosted on a Linux x86_64. -- Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
27.11.2011 19:10, Sven Barth пишет: On 27.11.2011 16:45, Sergei Gorelkin wrote: The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise suggests that the foreign thread raises exceptions and FPC tries to handle them. Error 255 is most likely caused by Halt(255) in rtl/inc/except.inc line 200 or 303, these are the only places where RTL can exit with code 255. This is explainable: FPC won't have ExceptObjectStack or ExceptAddressStack set up for the foreign thread, they will contain nil values. But I don't imagine how it manages to work *without* TLS callbacks. The difference is that RTL will remain in single-threaded mode, but SetUnhandledExceptionFilter that is used to intercept exceptions is AFAIK global and will still break in. Also interesting question: why does so far only Leonardo experience that problem? I myself have no problem building trunk on a Windows 7 machine using 2.4.4 as a starting compiler. He has some software which creates threads in compiler process. Maybe something specific to VM, maybe something specific to server OS. I also build trunk successfully on Windows XP (32bit) and Windows 7 (64bit), on both of them Process Explorer shows just a single thread in compiler process. Another point to look at is webtbs/tw2423.pp, testsuite shows it fails consistently with RTE 226, while I have never seen it failing locally. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk on Win32
On 27.11.2011 18:48, Sergei Gorelkin wrote: 27.11.2011 19:10, Sven Barth пишет: On 27.11.2011 16:45, Sergei Gorelkin wrote: The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise suggests that the foreign thread raises exceptions and FPC tries to handle them. Error 255 is most likely caused by Halt(255) in rtl/inc/except.inc line 200 or 303, these are the only places where RTL can exit with code 255. This is explainable: FPC won't have ExceptObjectStack or ExceptAddressStack set up for the foreign thread, they will contain nil values. But I don't imagine how it manages to work *without* TLS callbacks. The difference is that RTL will remain in single-threaded mode, but SetUnhandledExceptionFilter that is used to intercept exceptions is AFAIK global and will still break in. Also interesting question: why does so far only Leonardo experience that problem? I myself have no problem building trunk on a Windows 7 machine using 2.4.4 as a starting compiler. He has some software which creates threads in compiler process. Maybe something specific to VM, maybe something specific to server OS. I also build trunk successfully on Windows XP (32bit) and Windows 7 (64bit), on both of them Process Explorer shows just a single thread in compiler process. Another point to look at is webtbs/tw2423.pp, testsuite shows it fails consistently with RTE 226, while I have never seen it failing locally. I've remembered that I also have a Windows 2003 VM running on my Linux x86_64 system (using QEMU though). I did now run a make cycle and tested the test you mentioned (using the newly compiled compiler). No problems here (revision is 19692 - it's a coincidence though that it's directly before your change). I also checked the compiler process using Process Explorer: only one thread there. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
out vs. var (was: Re: [fpc-devel] Internal error in FPC 2.6.0rc1)
Hi Sergei
Am 25.11.2011 um 13:49 schrieb Sergei Gorelkin:
25.11.2011 13:36, Michael Müller пишет:
Hi,
I tested RC1 using one of my codes and ran into an internal error. I was
able to reduce the code to the following.
Free Pascal Compiler version 2.6.0rc1 [2011/10/15] for i386
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling InternalError.dpr
InternalError.dpr(21,3) Fatal: Internal error 201103063
Fatal: Compilation aborted
--- Code, start ---
{$IFDEF FPC}
{$MODE Delphi}
{$ENDIF}
program InternalError;
procedure SetArray({var}out SingleArray: array of Single; const Value:
Single);
var
I: Integer;
begin
for I := Low(SingleArray) to High(SingleArray) do
SingleArray[I] := Value;
end;
var
ValuesBuffer: array of Single;
begin
SetLength(ValuesBuffer, 5);
SetArray(ValuesBuffer, 5.7);
end.
--- Code, end ---
The error is at the beginning of SetArray() call.
I guess this one is for me to fix.
Thanks for the fix. Hopefully it finds it way into 2.6.
I see that the real error is in my code since the procedure parameter has to
be 'var' and not 'out' otherwise the dimension which is set outside will not
reach the procedure. But the compiler shouldn't stop with an internal error.
If it is changed to 'var' it compiles.
Frankly speaking, I doubt that. 'out' in this case likely refers to elements
of dynamic array, not to array itself. If it was e.g. 'array of ansistring'
then all its elements should be finalized before the call, then pointer to
first element and length passed to callee.
After your statement I played a little bit and it seems that you are right.
When using 'out' the length of the array reaches the procedure. But what
surprises me much more is that even values of the array reach the procedure. I
added a loop at the beginning of the procedure that print the array before the
(new) value is set and it shows the values that were set outside the procedure
after SetLength(). For an array of String the elements are emptied (as you
stated too). Does this mean that reference counted elements are emptied and the
others not? Beside that what is than the difference between 'out' and 'var'? (I
tested this also with Delphi 2009 with exact the same behaviour).
The Delphi help mentions that for 'out' parameters the referenced variable is
freed (or so) when it is given to the routine (I have only a German help
otherwise I would show the text here). This is exact the behaviour that I
expected. So for me it sounds that even Delphi is not doing it as stated in the
documentation. Where is my understanding wrong here?
Regards
Michael___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: out vs. var (was: Re: [fpc-devel] Internal error in FPC 2.6.0rc1)
On 28 Nov 2011, at 00:49, Michael Müller wrote: Does this mean that reference counted elements are emptied and the others not? Yes. Beside that what is than the difference between 'out' and 'var'? If you enable hints, the compiler will print a hint if it detects you passing a potentially uninitialized variable to a var parameter, while it won't print such a warning if you pass it to an out parameter. Additionally, if you use the -gt command line option then the compiler will overwrite the contents of (non-reference-counted) out-parameters in the function entry code. This switch will do nothing for open array parameters though, because it lacks support for using the hidden high parameter to determine the bounds of the array at run time. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
