[fpc-devel] Test, please ignore
Hello. Test, please ignore. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] test, please ignore
Hello, This is a test e-mail following some listsserver maintenance, please ignore. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test suite error wrong PPU
Hairy Pixels schrieb am Fr., 24. Juni 2022, 03:45: > > > > On Jun 23, 2022, at 11:52 PM, Sven Barth > wrote: > > > > As you can see at the end (see below) it falls back to 3.2.2 at the end. > What commands did you execute to build FPC itself? > > > > I have no idea what it did that. I’ve done this many times so I’m confused > as to what changed. > > I used a modified ppcaarch64.lpi file to build the compiler (from the > compiler sources itself) which I see uses 3.2.2 but then in the next lines > of output you can see where I use the newly built compiler to run a program > and it’s 3.3.1. > > lazbuild > /Users/ryanjoseph/Developer/fpc-gitlab/compiler/ryan_ppcaarch64.lpi > Hint: (lazarus) Build Project: nothing to do. > Free Pascal Compiler version 3.2.2 [2021/05/16] for aarch64 > Copyright (c) 1993-2021 by Florian Klaempfl and others > (1002) Target OS: Darwin for AArch64 > (3104) Compiling pp.pas > (3104) Compiling pgenutil.pas > (9009) Assembling pgenutil > (9009) Assembling pp > (9015) Linking /Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp > (1008) 4179 lines compiled, 0.7 sec > /Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp -vbr -gw > -godwarfcpp > -o/Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/tests/bin/test > -XR/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk > -Fu/Users/ryanjoseph/Developer/fpc-gitlab/rtl/units/aarch64-darwin > -FU/Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/output > /Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/tests/various/undefined_proc_var.pp > Free Pascal Compiler version 3.3.1 [2022/06/12] for aarch64 > It is not recommended to use the Lazarus project to build a compiler that is then used to run the testsuite. Please do a complete, ordinary build of FPC before running the testsuite. To do this execute the following in the main directory: make FPMAKEOPT="-T -j Where you replace "" with the amount of threads you want to use. If that finishes successfully then and only then you execute the testsuite with the compiler in compiler/ppca64. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test suite error wrong PPU
> On Jun 23, 2022, at 11:52 PM, Sven Barth wrote: > > As you can see at the end (see below) it falls back to 3.2.2 at the end. What > commands did you execute to build FPC itself? > I have no idea what it did that. I’ve done this many times so I’m confused as to what changed. I used a modified ppcaarch64.lpi file to build the compiler (from the compiler sources itself) which I see uses 3.2.2 but then in the next lines of output you can see where I use the newly built compiler to run a program and it’s 3.3.1. lazbuild /Users/ryanjoseph/Developer/fpc-gitlab/compiler/ryan_ppcaarch64.lpi Hint: (lazarus) Build Project: nothing to do. Free Pascal Compiler version 3.2.2 [2021/05/16] for aarch64 Copyright (c) 1993-2021 by Florian Klaempfl and others (1002) Target OS: Darwin for AArch64 (3104) Compiling pp.pas (3104) Compiling pgenutil.pas (9009) Assembling pgenutil (9009) Assembling pp (9015) Linking /Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp (1008) 4179 lines compiled, 0.7 sec /Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp -vbr -gw -godwarfcpp -o/Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/tests/bin/test -XR/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -Fu/Users/ryanjoseph/Developer/fpc-gitlab/rtl/units/aarch64-darwin -FU/Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/output /Users/ryanjoseph/Developer/Projects/FPC/compiler_gitlab/tests/various/undefined_proc_var.pp Free Pascal Compiler version 3.3.1 [2022/06/12] for aarch64 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test suite error wrong PPU
Hairy Pixels via fpc-devel schrieb am Do., 23. Juni 2022, 04:08: > I usually solve this by deleting the units folder but for some reason > after pulling from main it simply won’t build. Can anyone explain why the > PPU version is wrong? It’s all building from the same source directory so > the PPU version in ppu.pas should be the same. Before I tried this I did > build the RTL using the same compiler. > > The current version of the PPU is 208/16 and I’m not even sure what > version it’s looking for, it just says 208 is invalid. > As you can see at the end (see below) it falls back to 3.2.2 at the end. What commands did you execute to build FPC itself? > /Applications/Xcode.app/Contents/Developer/usr/bin/make -C fpmkunit > bootstrap FPC=/usr/local/lib/fpc/3.2.2/ppca64 > /usr/local/lib/fpc/3.2.2/ppca64 src/fpmkunit.pp > -Fu../../rtl/units/aarch64-darwin -FUunits_bs/aarch64-darwin > -Fu../paszlib/src -Fu../hash/src -Fi../paszlib/src > -Fi../fcl-process/src/unix -Fu../fcl-process/src > -Fi../fcl-process/src/darwin -Fi../fcl-process/src/dummy -Fu../libtar/src > -Fd -n > PPU Loading > /Users/ryanjoseph/Developer/fpc-gitlab/rtl/units/aarch64-darwin/system.ppu > PPU Invalid Version 208 > Fatal: Can't find unit system used by fpmkunit > Fatal: Compilation aborted > make[5]: *** [bootstrap] Error 1 > make[4]: *** [fpmake] Error 2 > make[3]: *** [packages-stamp.aarch64-darwin] Error 2 > make[2]: *** [tstunits] Error 2 > make[1]: *** [allexectests] Error 2 > make: *** [full] Error 2 > tests$ > Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Test suite error wrong PPU
I usually solve this by deleting the units folder but for some reason after
pulling from main it simply won’t build. Can anyone explain why the PPU version
is wrong? It’s all building from the same source directory so the PPU version
in ppu.pas should be the same. Before I tried this I did build the RTL using
the same compiler.
The current version of the PPU is 208/16 and I’m not even sure what version
it’s looking for, it just says 208 is invalid.
tests$ cd $HOME/Developer/fpc-gitlab/tests; make full
TEST_FPC=$HOME/Developer/fpc-gitlab/compiler/${FPC_ARCH}/pp
/Applications/Xcode.app/Contents/Developer/usr/bin/make clean
/bin/rm -f
/bin/rm -f gparmake createlst gparmake.o createlst.o gparmake.bc
createlst.bclibpgparmake.a libpcreatelst.a libimpgparmake.a libimpcreatelst.a
/bin/rm -rf gparmake.dSYM createlst.dSYM
/bin/rm -f fpcmade.aarch64-darwin *aarch64-darwin.fpm Package.fpc *.s
/bin/rm -f script*.res link*.res *_script.res *_link.res
/bin/rm -f ./ppas.sh *_ppas.sh ppas.sh ppaslink.sh
/Applications/Xcode.app/Contents/Developer/usr/bin/make clean_test
CPU_TARGET=aarch64 OS_TARGET=darwin SUBARCH=
/bin/rm -rf output/aarch64-darwin
/bin/rm -f core gmon.out testprep-stamp.aarch64-darwin dotgz.sh
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C tstunits clean
CPU_TARGET=aarch64 OS_TARGET=darwin SUBARCH=
/bin/rm -rf aarch64-darwin
/bin/rm -rf /Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/tmp
/bin/rm -f rtl-stamp.aarch64-darwin
/bin/rm -f units/aarch64-darwin/erroru.ppu units/aarch64-darwin/popuperr.ppu
units/aarch64-darwin/ptest.ppu
/bin/rm -rf units
/bin/rm -rf bin
/bin/rm -f *.o *.bc *.ppu *.rst *.s *.a *.so *.ppl
/bin/rm -rf *.sl
/bin/rm -f fpcmade.* Package.fpc *.fpm
/bin/rm -f script*.res link*.res *_script.res *_link.res
/bin/rm -f ./ppas.sh *_ppas.sh ppas.sh ppaslink.sh
/bin/rm -rf aarch64-darwin
/bin/rm -rf /Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/tmp
/bin/rm -f fpcunit-stamp.aarch64-darwin
/bin/rm -rf aarch64-darwin
/bin/rm -rf /Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/tmp
/bin/rm -f packages-stamp.aarch64-darwin
/bin/rm -f filelisttest.lst filelisttbs.lst filelisttbf.lst filelistwebtbs.lst
filelistwebtbf.lst
/Applications/Xcode.app/Contents/Developer/usr/bin/make allexectests
make[2]: `units/aarch64-darwin' is up to date.
/usr/local/lib/fpc/3.2.2/ppca64 -FE. utils/createlst.pp
Free Pascal Compiler version 3.2.2 [2021/05/16] for aarch64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Darwin for AArch64
Compiling utils/createlst.pp
createlst.pp(40,9) Warning: unreachable code
Assembling createlst
Linking ./createlst
72 lines compiled, 0.6 sec
1 warning(s) issued
make[2]: `units/aarch64-darwin' is up to date.
/usr/local/lib/fpc/3.2.2/ppca64 -FE. utils/gparmake.pp
Free Pascal Compiler version 3.2.2 [2021/05/16] for aarch64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Darwin for AArch64
Compiling utils/gparmake.pp
gparmake.pp(49,3) Note: Local variable "FileList" not used
Assembling gparmake
Linking ./gparmake
207 lines compiled, 0.5 sec
1 note(s) issued
/bin/mkdir -p output/aarch64-darwin
/Applications/Xcode.app/Contents/Developer/usr/bin/make gparmake_allexectests
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C utils utils
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C tstunits
FPC_VERSION= FPC=/Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp
NATIVE_FPC=/usr/local/lib/fpc/3.2.2/ppca64 CPU_TARGET=aarch64 OS_TARGET=darwin
SUBARCH= 'OPT= -Fd' CCOMPILER=/usr/bin/gcc BINUTILSPREFIX=
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../../rtl all
'OPT=-Fd -n' 'CROSSOPT='
FPC=/Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C darwin all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../../rtl install
INSTALL_PREFIX=/Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/tmp
INSTALL_UNITDIR=/Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/aarch64-darwin
OPT= CROSSOPT= FPC=/Users/ryanjoseph/Developer/fpc-gitlab/compiler/aarch64/pp
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C darwin all
/usr/local/bin/fpcmake -p -Taarch64-darwin Makefile.fpc
Processing Makefile.fpc
Writing Package.fpc
/usr/bin/install -m 755 -d
/Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/aarch64-darwin
/usr/bin/install -c -m 644 Package.fpc
/Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/aarch64-darwin
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C darwin install
/usr/bin/install -m 755 -d
/Users/ryanjoseph/Developer/fpc-gitlab/tests/tstunits/aarch64-darwin
/usr/bin/install -c -m 644 ../../rtl/units/aarch64-darwin/system.ppu
../../rtl/units/aarch64-darwin/sysinit.ppu
../../rtl/units/aarch64-darwin/uuchar.ppu
../../rtl/units/aarch64-darwin/unixtype.ppu
../../rtl/units/aarch64-darwin/ctypes.ppu
../../rtl/units/aarch64-darwin/objpas.ppu
[fpc-devel] test plz ignore
test plz ignore ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test
It seems to be working tho--Alexander Grotewohlhttp://dcclost.com___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test
> On Jun 15, 2019, at 11:04 AM, J. Gareth Moreton > wrote: > > It works! Everyone's just being very quiet for some reason. > > On 15/06/2019 14:40, Florian Klämpfl wrote: >> Please ignore ... >> ___ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel >> >> > I’ve tried to resend a message 3 times now but I still don’t see it. Not sure if everything’s working ok. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test
It works! Everyone's just being very quiet for some reason. On 15/06/2019 14:40, Florian Klämpfl wrote: Please ignore ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Test
Please ignore ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test/cg/variants/tnofalvarol.pp
So I did try building it manually with the trunk, and for some reason it failed on that as well, even though it didn't appear in the test suite as a failure. Definitely confusing, but it tells me that the failure might not be due to my changes. I'll keep an eye out though to see if anything crops up. Gareth aka. Kit On 03/05/2019 17:34, J. Gareth Moreton wrote: Thanks Jonas. On 03/05/2019 17:28, Jonas Maebe wrote: On 03/05/2019 17:48, J. Gareth Moreton wrote: So I was doing some refactoring work, and ran the test suites to see if nothing broke. It turned out that I got a single failure in test/cg/variants/tnofalvarol.pp - seems a little odd because my changes weren't meant to change the output of binary files in any way. But looking at the test in question, all I get is a wall of $include definitions. Running it in Lazarus isn't too helpful either because the stack trace doesn't reveal where the erroneous line is, only that seven levels down, an error occurs in "destructor tdynarrayiter.done;" in the variants unit, but doesn't know which line exactly - exception EVariantError with message: "Invalid variant type cast". "destructor tdynarrayiter.done;" is part of packages/rtl-objpas/src/inc/variants.pp. You don't get more information because all units from the packages directory are compiled with optimizations and without debug information by default. You will have to compile that unit with debug information (you can add OPT="-O- -gw" to the make command when building all of FPC to get everything built without optimizations and with debug information). I suppose what I'm trying to get at is that this test is not very self-contained and is very hard to debug if it happens to fail, and I would consider rewriting or replacing it. The files it includes have been automatically generated, automatically tested against Kylix, and then a) if the program compiled with Kylix, it was run to see which overload Kylix picked and whether it generated an exception, and a "halt(1)" was (also automatically) placed in the other paths. All successfully executing tests are included in tnofalvarol.pp to make the test go faster (compiling and running one program with 100 include files is much faster than compiling 100 separate files) b) if the program did not compile with Kylix, it was kept as a separate program (since if you include two failing programs in a single program and it fails to compile, we can't test whether both errors were detected). You can still compile the individual include files of the test as separate programs to test and debug them separately. Once you compile the variants unit with debug information, you should be able to easily see which individual test is crashing based on the backtrace. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test/cg/variants/tnofalvarol.pp
On 03/05/2019 17:48, J. Gareth Moreton wrote: So I was doing some refactoring work, and ran the test suites to see if nothing broke. It turned out that I got a single failure in test/cg/variants/tnofalvarol.pp - seems a little odd because my changes weren't meant to change the output of binary files in any way. But looking at the test in question, all I get is a wall of $include definitions. Running it in Lazarus isn't too helpful either because the stack trace doesn't reveal where the erroneous line is, only that seven levels down, an error occurs in "destructor tdynarrayiter.done;" in the variants unit, but doesn't know which line exactly - exception EVariantError with message: "Invalid variant type cast". "destructor tdynarrayiter.done;" is part of packages/rtl-objpas/src/inc/variants.pp. You don't get more information because all units from the packages directory are compiled with optimizations and without debug information by default. You will have to compile that unit with debug information (you can add OPT="-O- -gw" to the make command when building all of FPC to get everything built without optimizations and with debug information). I suppose what I'm trying to get at is that this test is not very self-contained and is very hard to debug if it happens to fail, and I would consider rewriting or replacing it. The files it includes have been automatically generated, automatically tested against Kylix, and then a) if the program compiled with Kylix, it was run to see which overload Kylix picked and whether it generated an exception, and a "halt(1)" was (also automatically) placed in the other paths. All successfully executing tests are included in tnofalvarol.pp to make the test go faster (compiling and running one program with 100 include files is much faster than compiling 100 separate files) b) if the program did not compile with Kylix, it was kept as a separate program (since if you include two failing programs in a single program and it fails to compile, we can't test whether both errors were detected). You can still compile the individual include files of the test as separate programs to test and debug them separately. Once you compile the variants unit with debug information, you should be able to easily see which individual test is crashing based on the backtrace. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] test/cg/variants/tnofalvarol.pp
So I was doing some refactoring work, and ran the test suites to see if nothing broke. It turned out that I got a single failure in test/cg/variants/tnofalvarol.pp - seems a little odd because my changes weren't meant to change the output of binary files in any way. But looking at the test in question, all I get is a wall of $include definitions. Running it in Lazarus isn't too helpful either because the stack trace doesn't reveal where the erroneous line is, only that seven levels down, an error occurs in "destructor tdynarrayiter.done;" in the variants unit, but doesn't know which line exactly - exception EVariantError with message: "Invalid variant type cast". I suppose what I'm trying to get at is that this test is not very self-contained and is very hard to debug if it happens to fail, and I would consider rewriting or replacing it. Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test changes in e.g. a package
Op 18-07-18 om 13:39 schreef Michael Van Canneyt: On Wed, 18 Jul 2018, Bart wrote: Hi, Sorry if this is a RTFM question. Whenever I make some changes to the sourcecode of e.g. a package or an RTL-file, in order to test these changes I do a make clean/make install in the root directory. (e.g. I change one line in packages/fcl-registry/src/regini.inc) This takes several minutes (which especially sucks if I made a typo which leads to a syntax error). Is there a faster way to do this? In general: no. No? cd packages/fcl-registry fppkg install That's it. It will also re-compile and install all packages that depend on fcl-registry. Use 'fppkg install -o -gl' when you need debug-info. Your fppkg configuration has to be correct, though. Which is the case when you used the fpc-installer. If it does not work, use 'fppkg listsettings' and check the results. Regards, Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test changes in e.g. a package
On Wed, 18 Jul 2018, Bart wrote: On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt wrote: In general: no. OK I pity the compiler devels, especially in the past with slower hardware. Yes, it can be time-consuming. But: * if the package does not have dependencies, you can just recompile that package. cd packages/fcl-registry make clean allOPT=-gl && sudo make install That failed with incompatible ppu version (make calls fpc 3.0.4) If you try this after having done a 'make all' then that is normal, since the system is set up to use the units in the source tree, not the installed ones. And the ones in the source tree were then compiled with the trunk compiler... So you should then specify the trunk compiler: make clean all OPT=-gl PP=/path/to/trunk/compiler (or install it on the PATH) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test changes in e.g. a package
Bart schrieb am Mi., 18. Juli 2018, 23:36: > On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt > wrote: > > > In general: no. > > OK > I pity the compiler devels, especially in the past with slower hardware. > The compiler devels more often than not only work with the compiler and RTL directories and there a "make cycle" in the compiler directory is sufficient. :) > > > > But: > > * if the package does not have dependencies, you can just recompile that > > package. > > cd packages/fcl-registry > > make clean allOPT=-gl && sudo make install > > That failed with incompatible ppu version (make calls fpc 3.0.4) > You're trying to compile a trunk package not a 3.0.4 package? Then maybe it helps to pass the trunk compiler binary with FPC=/path/to/binary Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test changes in e.g. a package
On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt wrote: > In general: no. OK I pity the compiler devels, especially in the past with slower hardware. > > But: > * if the package does not have dependencies, you can just recompile that > package. > cd packages/fcl-registry > make clean allOPT=-gl && sudo make install That failed with incompatible ppu version (make calls fpc 3.0.4) > * For units that can be tested directly, copy the unit to the directory > where your test program is, recompile till OK. Thanks for the explanation. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test changes in e.g. a package
On Wed, 18 Jul 2018, Bart wrote: Hi, Sorry if this is a RTFM question. Whenever I make some changes to the sourcecode of e.g. a package or an RTL-file, in order to test these changes I do a make clean/make install in the root directory. (e.g. I change one line in packages/flc-registry/src/regini.inc) This takes several minutes (which especially sucks if I made a typo which leads to a syntax error). Is there a faster way to do this? In general: no. But: * if the package does not have dependencies, you can just recompile that package. cd packages/fcl-registry make clean allOPT=-gl && sudo make install * For units that can be tested directly, copy the unit to the directory where your test program is, recompile till OK. When possible, I do the latter. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Test changes in e.g. a package
Hi, Sorry if this is a RTFM question. Whenever I make some changes to the sourcecode of e.g. a package or an RTL-file, in order to test these changes I do a make clean/make install in the root directory. (e.g. I change one line in packages/flc-registry/src/regini.inc) This takes several minutes (which especially sucks if I made a typo which leads to a syntax error). Is there a faster way to do this? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Test, please ignore
___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] test on TP
Can sb test this program on TP/BP7 and tell me the result? Thank you.
program sometest;
{$ifdef fpc}
{$mode tp}
{$endiof}
Type
PChildThing = ^TChildThing;
TChildThing = object
constructor init;
end;
PSomething = ^TSomething;
TSomething = object
ct:PChildThing;
constructor init;
end;
constructor TSomething.init;
begin
new(ct,init);
end;
var p : PSomething;
constructor TChildThing.Init;
begin
if assigned(p) then
writeln('assigned')
else
writeln('not assigned')
end;
begin
p:=nil;
p:=new(PSomething,Init);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test on TP
BP 7.0 (real)
BP7.0 (protected)
VP2.1b279
all: not assigned
- Original Message -
From: Marco van de Voort mar...@stack.nl
To: fpc-devel@lists.freepascal.org
Sent: Wednesday, May 14, 2014 11:46 AM
Subject: [fpc-devel] test on TP
Can sb test this program on TP/BP7 and tell me the result? Thank you.
program sometest;
{$ifdef fpc}
{$mode tp}
{$endiof}
Type
PChildThing = ^TChildThing;
TChildThing = object
constructor init;
end;
PSomething = ^TSomething;
TSomething = object
ct:PChildThing;
constructor init;
end;
constructor TSomething.init;
begin
new(ct,init);
end;
var p : PSomething;
constructor TChildThing.Init;
begin
if assigned(p) then
writeln('assigned')
else
writeln('not assigned')
end;
begin
p:=nil;
p:=new(PSomething,Init);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test on TP
On Wed, May 14, 2014 12:10, Gerhard Scholz wrote:
BP 7.0 (real)
BP7.0 (protected)
VP2.1b279
all: not assigned
Indeed (apart from the obvious typo endiof preventing compilation, of
course). Why / how could it give a different result?
Tomas
- Original Message -
From: Marco van de Voort mar...@stack.nl
To: fpc-devel@lists.freepascal.org
Sent: Wednesday, May 14, 2014 11:46 AM
Subject: [fpc-devel] test on TP
Can sb test this program on TP/BP7 and tell me the result? Thank you.
program sometest;
{$ifdef fpc}
{$mode tp}
{$endiof}
Type
PChildThing = ^TChildThing;
TChildThing = object
constructor init;
end;
PSomething = ^TSomething;
TSomething = object
ct:PChildThing;
constructor init;
end;
constructor TSomething.init;
begin
new(ct,init);
end;
var p : PSomething;
constructor TChildThing.Init;
begin
if assigned(p) then
writeln('assigned')
else
writeln('not assigned')
end;
begin
p:=nil;
p:=new(PSomething,Init);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test on TP
In our previous episode, Tomas Hajny said: Indeed (apart from the obvious typo endiof preventing compilation, of course). Why / how could it give a different result? I'm hunting down a problem with the TV form editor. (you replied in the thread on the forum). The problem had this rough structure, but it could be this, or that the order of events fired is different. (IOW FV fires certain events from the constructor and TV not). The latter is harder to debug, so I wanted to make sure it wasn't some language difference. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test on TP
On 14 May 2014, at 13:38, Marco van de Voort wrote: In our previous episode, Tomas Hajny said: Indeed (apart from the obvious typo endiof preventing compilation, of course). Why / how could it give a different result? I'm hunting down a problem with the TV form editor. (you replied in the thread on the forum). The problem had this rough structure, but it could be this, or that the order of events fired is different. (IOW FV fires certain events from the constructor and TV not). You may have forgotten to put something in your test code in that case, because you don't assign anything to p anywhere. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test on TP
In our previous episode, Jonas Maebe said: I'm hunting down a problem with the TV form editor. (you replied in the thread on the forum). The problem had this rough structure, but it could be this, or that the order of events fired is different. (IOW FV fires certain events from the constructor and TV not). You may have forgotten to put something in your test code in that case, because you don't assign anything to p anywhere. I think not. I really wanted to check that the result of the allocation wasn't stored to p before the constructor ran. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Test, please ignore
___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test, please ignore
Am 25.01.2014 17:06, schrieb Florian Klaempfl: Sorry, I forgot to setup up cleaning up backups so the mailing list server ran out of disk space. So it stopped working, it should be back again. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] test results trunk - Re: probably incorrect debug-line-info generated by fpc 2.6.2 and trunk
On 19/01/2014 16:48, Martin wrote: (Existing tests are still running, but since this is for feedback, the results can be submitted later) UNMODIFIED TRUNK rev 26506: utils/digest output/i386-win32/log Total = 6874 (24:6850) Total number of compilations = 4177 (7:4170) Successfully compiled = 3146 Successfully failed = 1024 Compilation failures = 4 Compilation that did not fail while they should = 3 Total number of runs = 2697 (17:2680) Successful runs = 2680 Failed runs = 17 Number units compiled = 132 Number program that should not be run = 314 Number of skipped tests = 240 Number of skipped graph tests = 10 Number of skipped interactive tests = 30 Number of skipped known bug tests = 6 Number of skipped tests for other versions = 4 Number of skipped tests for other cpus = 53 Number of skipped tests for other targets = 137 TRUNK with peephole change rev 26518 (12 revisions later) utils/digest output/i386-win32/log Total = 6874 (19:6855) Total number of compilations = 4177 (7:4170) Successfully compiled = 3146 Successfully failed = 1024 Compilation failures = 4 Compilation that did not fail while they should = 3 Total number of runs = 2697 (12:2685) Successful runs = 2685 Failed runs = 12 Number units compiled = 132 Number program that should not be run = 314 Number of skipped tests = 240 Number of skipped graph tests = 10 Number of skipped interactive tests = 30 Number of skipped known bug tests = 6 Number of skipped tests for other versions = 4 Number of skipped tests for other cpus = 53 Number of skipped tests for other targets = 137 Since I have failing tests either way, it is hard to say anything about the change. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test results trunk - Re: probably incorrect debug-line-info generated by fpc 2.6.2 and trunk
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Martin Envoyé : dimanche 19 janvier 2014 18:42 À : FPC developers' list Objet : [fpc-devel] test results trunk - Re: probably incorrect debug- line-info generated by fpc 2.6.2 and trunk On 19/01/2014 16:48, Martin wrote: (Existing tests are still running, but since this is for feedback, the results can be submitted later) UNMODIFIED TRUNK rev 26506: utils/digest output/i386-win32/log Total = 6874 (24:6850) Total number of compilations = 4177 (7:4170) Successfully compiled = 3146 Successfully failed = 1024 Compilation failures = 4 Compilation that did not fail while they should = 3 Total number of runs = 2697 (17:2680) Successful runs = 2680 Failed runs = 17 Number units compiled = 132 Number program that should not be run = 314 Number of skipped tests = 240 Number of skipped graph tests = 10 Number of skipped interactive tests = 30 Number of skipped known bug tests = 6 Number of skipped tests for other versions = 4 Number of skipped tests for other cpus = 53 Number of skipped tests for other targets = 137 TRUNK with peephole change rev 26518 (12 revisions later) utils/digest output/i386-win32/log Total = 6874 (19:6855) Total number of compilations = 4177 (7:4170) Successfully compiled = 3146 Successfully failed = 1024 Compilation failures = 4 Compilation that did not fail while they should = 3 Total number of runs = 2697 (12:2685) Successful runs = 2685 Failed runs = 12 Number units compiled = 132 Number program that should not be run = 314 Number of skipped tests = 240 Number of skipped graph tests = 10 Number of skipped interactive tests = 30 Number of skipped known bug tests = 6 Number of skipped tests for other versions = 4 Number of skipped tests for other cpus = 53 Number of skipped tests for other targets = 137 Since I have failing tests either way, it is hard to say anything about the change. Hi Martin, if you want to compare to test runs, you should save at least three files at the end of each run: output/$fpctarget/faillist output/$fpctarget/log and output/$fpctarget/longlog The best is to first compare the two log files with diff utility. Inside longlog, you should be able to find more information about the differences. In the hope this can help you, Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test results trunk - Re: probably incorrect debug-line-info generated by fpc 2.6.2 and trunk
On 19/01/2014 22:31, Pierre Free Pascal wrote: if you want to compare to test runs, you should save at least three files at the end of each run: output/$fpctarget/faillist output/$fpctarget/log and output/$fpctarget/longlog The best is to first compare the two log files with diff utility. Inside longlog, you should be able to find more information about the differences. In the hope this can help you, Thanks. Eventually I will need to run them from the same checkout. I run the same revision, but from 2 checkouts (for convenience), but I guess some option to make must have differed. My modifications fail 5 tests less. They are peephole opt, they should not fix anything, and I do doubt that they did. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] test
... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test message - please disregard
This is a test message to check that the list bot is getting the correct address now. My apologies for the white noise. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test suit compilation is broken for win32-i386 after r21341?
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling redir.pp
redir.pp(980,41) Error: Identifier not found cint
redir.pp(980,47) Error: Identifier not found cint
redir.pp(983,6) Warning: Comparison might be always false due to range of
constant and expression
redir.pp(983,15) Warning: unreachable code
redir.pp(984,14) Error: Identifier not found wifexited
redir.pp(985,41) Error: Identifier not found wexitstatus
redir.pp(986,12) Warning: Comparison might be always true due to range of
constant and expression
redir.pp(988,2) Error: Operator is not overloaded: - erroneous type
redir.pp(1089) Fatal: There were 5 errors compiling module, stopping
Fatal: Compilation aborted
...
This piece of code (TransformfpSystemToShell) was introduced in r21341, if I
understand right.
Should it be surrounded by {$ifdef UNIX} as it's done for
TransformfpSystemToShell call itself?..
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test suit compilation is broken for win32-i386 after r21341?
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling redir.pp
redir.pp(980,41) Error: Identifier not found cint
redir.pp(980,47) Error: Identifier not found cint
redir.pp(983,6) Warning: Comparison might be always false due to range of
constant and expression
redir.pp(983,15) Warning: unreachable code
redir.pp(984,14) Error: Identifier not found wifexited
redir.pp(985,41) Error: Identifier not found wexitstatus
redir.pp(986,12) Warning: Comparison might be always true due to range of
constant and expression
redir.pp(988,2) Error: Operator is not overloaded: - erroneous type
redir.pp(1089) Fatal: There were 5 errors compiling module, stopping
Fatal: Compilation aborted
...
This piece of code (TransformfpSystemToShell) was introduced in r21341, if I
understand right.
Should it be surrounded by {$ifdef UNIX} as it's done for
TransformfpSystemToShell call itself?..
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Test suit compilation is broken for win32-i386 after r21341?
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Max Nazhalov
Envoyé : dimanche 20 mai 2012 17:37
À : FPC Developers' list
Objet : [fpc-devel] Test suit compilation is broken for win32-i386 after
r21341?
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling redir.pp
redir.pp(980,41) Error: Identifier not found cint
redir.pp(980,47) Error: Identifier not found cint
redir.pp(983,6) Warning: Comparison might be always false due to range of
constant and expression
redir.pp(983,15) Warning: unreachable code
redir.pp(984,14) Error: Identifier not found wifexited
redir.pp(985,41) Error: Identifier not found wexitstatus
redir.pp(986,12) Warning: Comparison might be always true due to range of
constant and expression
redir.pp(988,2) Error: Operator is not overloaded: - erroneous type
redir.pp(1089) Fatal: There were 5 errors compiling module, stopping
Fatal: Compilation aborted
...
This piece of code (TransformfpSystemToShell) was introduced in r21341,
if
I understand right.
Should it be surrounded by {$ifdef UNIX} as it's done for
TransformfpSystemToShell call itself?..
Thanks, I committed a fix in rev 21346
Pierre
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target when
they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copies the libraries when
the are compiled. No need to expand the %needlibrary directive.
Regards, Bernd.
Index: tests/utils/dotest.pp
===
--- tests/utils/dotest.pp (Revision 17610)
+++ tests/utils/dotest.pp (Arbeitskopie)
@@ -930,6 +930,8 @@
str(Config.Timeout,s);
execcmd:=execcmd+s;
end;
+ if Config.NeedLibrary then
+ execcmd:=execcmd+'export LD_LIBRARY_PATH='+RemotePath + ' ; ';
{ as we moved to RemotePath, if path is not absolute
we need to use ./execfilename only }
if not isabsolute(TestRemoteExe) then
@@ -1185,6 +1187,8 @@
var
PPDir : string;
Res : boolean;
+ LocalLibraryFile, LibraryFileName: String;
+ execres: Boolean;
begin
Res:=GetConfig(PPFile[current],Config);
@@ -1398,6 +1402,20 @@
begin
if (Config.NoRun) then
begin
+if (CompilerTarget = 'linux') and (RemoteAddr '') then
+{ if test program is a library, copy the library to the target }
+begin
+ LibraryFileName:= 'lib' +
ForceExtension(SplitFileName(PPFile[current]), 'so');
+ LocalLibraryFile:= OutputDir + '/' + SplitPath(PPFile[current]) +
LibraryFileName;
+ if FileExists(LocalLibraryFile) then
+ begin
+ execres:=ExecuteRedir(rcpprog,RemotePara+' '+ LocalLibraryFile+'
'+RemoteAddr+':' + RemotePath+'/'+ LibraryFileName,'',EXELogFile,'stdout');
+ if not execres then
+ begin
+Verbose(V_normal, 'Could not copy library ' + LibraryFileName);
+ end;
+ end;
+end;
{ avoid a second attempt by writing to elg file }
AddLog(EXELogFile,skipping_run_test+PPFileInfo[current]);
AddLog(ResLogFile,skipping_run_test+PPFileInfo[current]);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:04, Bernd Mueller wrote: Jonas Maebe wrote: Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? this second approach (which works well for me) copies the libraries when the are compiled. No need to expand the %needlibrary directive. Why do you limit it to Linux targets? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 30 May 2011, at 11:04, Bernd Mueller wrote: Jonas Maebe wrote: Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? this second approach (which works well for me) copies the libraries when the are compiled. No need to expand the %needlibrary directive. Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:37, Bernd Mueller wrote: Jonas Maebe wrote: Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. Most other targets use libc by default anyway (and if new non-libc targets are added or brought back to life, the ifdef can be adjusted in case the libc dependency would cause problems). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] test suite, problem with missing libraries on the target
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Bernd Mueller Envoyé : lundi 30 mai 2011 11:38 À : FPC developers' list Objet : Re: [fpc-devel] test suite, problem with missing libraries on the target Jonas Maebe wrote: On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Just add a LibExt constant to dotest.pp source with the same conditionals as for ExeExt, this should be enough. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Pierre Free Pascal wrote:
Just add a LibExt constant to dotest.pp source
with the same conditionals as for ExeExt, this should be enough.
const
ObjExt='o';
PPUExt='ppu';
{$ifdef UNIX}
ExeExt='';
LibExt='so';
{$else UNIX}
{$ifdef MACOS}
ExeExt='';
LibExt='so';
{$else MACOS}
ExeExt='exe';
LibExt='dll'; ???
{$endif MACOS}
{$endif UNIX}
but wouldn't that fail with crosscompiling? I am crosscompiling from a
Windows host.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve the library suffix for the host? So, when I am crosscompiling from Windows, I would get the wrong suffix for the Linux target? Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 13:53, Bernd Mueller wrote: Jonas Maebe wrote: Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve the library suffix for the host? Yes, your right... Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote:
On 23 May 2011, at 11:49, Bernd Mueller wrote:
I am running the test suite with remote execution (from a Windows
host) on an ARM-Linux target. Some test programs fail at runtime,
because they depend on libraries, which were not automatically copied
to the target. For example:
Failed to run test/tlib1b.pp 2011/01/21 18:06:08 (16)
/mnt/tlib1b: can't load library 'libtlib1a.so'
My target has very low resources so that I can not run the test suite
directly on the target. How can my problem be solved?
Maybe you are using TEST_DELTEMP=1? If so, remove it if you have enough
disk space on the remote target. Most test sources that are later on
used by other tests don't contain the necessary { %neededafter }
directive, so they are immediately deleted even when they are still
required later
Alternatively, you can submit a patch that adds { %neededafter } to all
affected tests).
I have enough FLASH memory, so I am not using TEST_DELTEMP=1. I had a
look into the test suite source and I think, that the test suite is not
able to copy the libraries to the target.
I attached a small patch, which could be a solution for the problem. I
am using the parameter of the %needlibrary directive to get the
information, which library should be copied. For example in tlib1b.pp,
the directive is expanded to { %needlibrary=tlib1a }. This works for me.
If you think, this patch could be the right way to copy the libraries, I
would submit a second patch which expands all required %needlibrary
directives.
Regards, Bernd.
Index: tests/utils/dotest.pp
===
--- tests/utils/dotest.pp (Revision 17059)
+++ tests/utils/dotest.pp (Arbeitskopie)
@@ -811,6 +811,7 @@
index: integer;
EndTicks,
StartTicks : int64;
+ LibraryFileName, LocalLibraryFile: string;
function ExecuteRemote(const prog,args:string):boolean;
var
Trials : longint;
@@ -913,6 +914,21 @@
s:=copy(s,index+1,length(s)-index);
until false;
end;
+
+ { copy library to target }
+ if (CompilerTarget = 'linux') and (Config.LibraryName '') then
+ begin
+ LibraryFileName:= 'lib' + Config.LibraryName + '.so';
+ LocalPath:=SplitPath(PPFile[current]);
+ LocalLibraryFile:= OutputDir + '/' + LocalPath + LibraryFileName;
+ execres:=ExecuteRemote(rcpprog,RemotePara+' '+ LocalLibraryFile+'
'+RemoteAddr+':' + RemotePath+'/'+ LibraryFileName);
+ if not execres then
+ begin
+ Verbose(V_normal, 'Could not copy library ' + LibraryFileName);
+ goto done;
+ end;
+ end;
+
{ rsh doesn't pass the exitcode, use a second command to print the
exitcode
on the remoteshell to stdout }
if DoVerbose and (rshprog='plink') then
@@ -936,6 +952,8 @@
execcmd:=execcmd+' ./'+SplitFileName(TestRemoteExe)
else
execcmd:=execcmd+' '+TestRemoteExe;
+ if Config.LibraryName '' then
+execcmd:=execcmd+' ; export LD_LIBRARY_PATH='+RemotePath;
execcmd:=execcmd+' ; echo TestExitCode: $?';
if (deAfter in DelExecutable) and
not Config.NeededAfter then
Index: tests/utils/testu.pp
===
--- tests/utils/testu.pp(Revision 17059)
+++ tests/utils/testu.pp(Arbeitskopie)
@@ -28,6 +28,7 @@
KnownCompileError : longint;
NeedRecompile : boolean;
NeedLibrary : boolean;
+LibraryName : string;
NeededAfter : boolean;
IsInteractive : boolean;
IsKnownRunError,
@@ -212,7 +213,10 @@
r.NoRun:=true
else
if GetEntry('NEEDLIBRARY') then
-r.NeedLibrary:=true
+begin
+ r.NeedLibrary:=true;
+ r.LibraryName:= res;
+end
else
if GetEntry('NEEDEDAFTER') then
r.NeededAfter:=true
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 27 May 2011, at 14:56, Bernd Mueller wrote:
I have enough FLASH memory, so I am not using TEST_DELTEMP=1. I had
a look into the test suite source and I think, that the test suite
is not able to copy the libraries to the target.
I attached a small patch, which could be a solution for the problem.
I am using the parameter of the %needlibrary directive to get the
information, which library should be copied. For example in
tlib1b.pp, the directive is expanded to { %needlibrary=tlib1a }.
This works for me.
If you think, this patch could be the right way to copy the
libraries, I would submit a second patch which expands all required
%needlibrary directives.
Isn't it easier to simply copy all compiled libraries to the target
when they are compiled (just like compiled test programs are copied)?
I thought that was already being done, but if I understand you
correctly that's not the case.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 27 May 2011, at 14:56, Bernd Mueller wrote: If you think, this patch could be the right way to copy the libraries, I would submit a second patch which expands all required %needlibrary directives. Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? I thought that was already being done, but if I understand you correctly that's not the case. you are right, it would probably be better to copy the libraries to the target when the are compiled. I have to look into the code, how that can be done. All I can say for now (without the patch) the libraries were produced by the compiler, but remain on the host. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test suite, problem with missing libraries on the target
Hello, I am running the test suite with remote execution (from a Windows host) on an ARM-Linux target. Some test programs fail at runtime, because they depend on libraries, which were not automatically copied to the target. For example: Failed to run test/tlib1b.pp 2011/01/21 18:06:08 (16) /mnt/tlib1b: can't load library 'libtlib1a.so' My target has very low resources so that I can not run the test suite directly on the target. How can my problem be solved? Thanks. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 23 May 2011, at 11:49, Bernd Mueller wrote:
I am running the test suite with remote execution (from a Windows
host) on an ARM-Linux target. Some test programs fail at runtime,
because they depend on libraries, which were not automatically
copied to the target. For example:
Failed to run test/tlib1b.pp 2011/01/21 18:06:08 (16)
/mnt/tlib1b: can't load library 'libtlib1a.so'
My target has very low resources so that I can not run the test
suite directly on the target. How can my problem be solved?
Maybe you are using TEST_DELTEMP=1? If so, remove it if you have
enough disk space on the remote target. Most test sources that are
later on used by other tests don't contain the necessary
{ %neededafter } directive, so they are immediately deleted even when
they are still required later
Alternatively, you can submit a patch that adds { %neededafter } to
all affected tests).
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test
___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test: compiling packages
The conference departure got shifted by one day, so I can answer you today, but then not until Friday :P Am 21.09.2010 00:30, schrieb Willibald Krenn: fpc -Fuunits\x86_64-win64 rtl.ppk unknown: 12 unknown: 12 rtl.ppk(7) Error: Multiple defined symbol _DLLMainCRTStartup rtl.ppk(7) Error: Undefined symbol: PASCALMAIN rtl.ppk(7) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted This does indeed seem like a problem in the Win64 compiler cause the Win32 one is working (are you using the trunk version?) If you have problems regarding this procedure, please don't hesitate to ask (but I might not be able to answer till Thursday, cause I'm on a developer conference). Thanks! Well, I guess I have to get a debug-build of fpc first and then I'll probably have to investigate where the unknown: 12 is coming from, etc.. You can compile and debug FPC from within Lazarus IDE. Just open compiler/pp.lpi (or maybe compiler/ppx86_64.lpi in your case) and compile it (for 2.5.1 you need a 2.4.0 as compiler for the compiler). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test: compiling packages
Am 19.09.2010 22:34, schrieb Willibald Krenn: Hi Sven! Am 19.09.2010 13:49, schrieb Sven Barth: and the following for Windows: pp -Twin32 -Fuunits/i386-win32 rtl.ppk I tried this with my 64 bit-head version of fpc, but it failed to produce any output except an .a and an .o file. fpc -Twin64 -Fuunits\x86_64-win64 rtl.ppk unknown: 12 unknown: 12 rtl.ppk(7) Error: PPU is already in a library : C:\source\fpcwilli\units\x86_64-win64\rtl\system.ppu rtl.ppk(7) Error: Multiple defined symbol _DLLMainCRTStartup rtl.ppk(7) Error: Undefined symbol: PASCALMAIN rtl.ppk(7) Fatal: There were 3 errors compiling module, stopping Fatal: Compilation aborted Error: C:\source\fpcwilli\bin\x86_64-win64\ppcx64.exe returned an error exitcode (normal if you did not specify a source file to be compiled) So I guess there's more work to be done on the win64 target: I will look into this once I have a debug build of trunk (see my other mail) on my disk. Try the following: - create a new test directory (I'll call it c:\test now) - copy the following directories from FPC's source to c:\test (you can put them directly into that directory with a rtl dir): - rtl\inc - rtl\x86_64 - rtl\win - rtl\win64 - create the directory c:\test\units\x86_64-win64 - open cmd and go to c:\test - execute the following command: fpc -Us -Sg -Fiinc -Fix86_64 -Fiwin -Fiwin64 -FUunits\x86_64-win64 win64\system.pp Now you should have a system.ppu and a system.o in c:\test\units\x86_64-win64. Now you create the rtl.ppk in c:\test and run the compiler using the following command: fpc -Fuunits\x86_64-win64 rtl.ppk Note: You need to recompile the system.pp once you've tried to compile the rtl.ppk or you'll get the error you mentioned. If you have problems regarding this procedure, please don't hesitate to ask (but I might not be able to answer till Thursday, cause I'm on a developer conference). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test: compiling packages
- execute the following command: fpc -Us -Sg -Fiinc -Fix86_64 -Fiwin -Fiwin64 -FUunits\x86_64-win64 win64\system.pp Had to change it to fpc -Us -Sg -Firtl\inc -Firtl\x86_64 -Firtl\win -Firtl\win64 -FUunits\x86_64-win64 rtl\win64\system.pp but this worked, as expected. Now you should have a system.ppu and a system.o in c:\test\units\x86_64-win64. Now you create the rtl.ppk in c:\test and run the compiler using the following command: fpc -Fuunits\x86_64-win64 rtl.ppk This did not work: type rtl.ppk package rtl; contains system; end. fpc -Fuunits\x86_64-win64 rtl.ppk unknown: 12 unknown: 12 rtl.ppk(7) Error: Multiple defined symbol _DLLMainCRTStartup rtl.ppk(7) Error: Undefined symbol: PASCALMAIN rtl.ppk(7) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted If you have problems regarding this procedure, please don't hesitate to ask (but I might not be able to answer till Thursday, cause I'm on a developer conference). Thanks! Well, I guess I have to get a debug-build of fpc first and then I'll probably have to investigate where the unknown: 12 is coming from, etc.. Anyway, thanks for your help on this! Cheers, Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test: compiling packages
Hello together!
After the previous thread about packages I experimented a bit more with
them.
I tried to compile the following package:
source begin
package rtl;
contains
system;
end.
source end
The system unit was precompiled by me for Win32 and for Linux.
The following call was used for Linux:
pp -Fuunits/i386-linux rtl.ppk
and the following for Windows:
pp -Twin32 -Fuunits/i386-win32 rtl.ppk
For Linux I needed to apply the following patch to the compiler to reach
linking stage:
patch begin
Index: compiler/expunix.pas
===
--- compiler/expunix.pas(Revision 16005)
+++ compiler/expunix.pas(Arbeitskopie)
@@ -142,6 +142,7 @@
while assigned(hp2) do
begin
if (not hp2.is_var) and
+(assigned(hp2.sym)) and
(hp2.sym.typ=procsym) then
begin
{ the manglednames can already be the same when the procedure
patch end
And now I get a linking error, because the exports of the package are
added as an import library. Thus the package tries to import itself
which fails on Linux. With target win32 it works, but an objdump shows this:
output begin
00025028 00025158 00025734 00025264
DLL Name: rtl
vma: Hint/Ord Member-Name Bound-To
256c4 3 FPC_WIDEINITTABLES
output end
The source of the problem seems to be in pmodules line 1960 where
createimportlibfromexports is called.
Removing this call results in a linking error on Win32
(FPC_WIDEINITTABLES not found) and on Linux in library.
The Windows package is created as rtl.dll and the Linux one as
librtl.so, although I expected rtl.ppl for Win32 and librtl.ppl
for Linux or even rtl-2.5.1.ppl and librtl-2.5.1.ppl on the
respective platforms. So this needs to be fixed as well.
I then tried to compile the following sample program for Linux, but it
also required the units si_prc and fpintres which I compiled
manually then:
source begin
program test;
begin
Write('Hello World');
end.
source end
As long as system.o was still in the units directory FPC just linked
that in. Once I renamed it the compiler (or better: the linker)
complained about it missing. So the compiler might not yet check whether
a shared lib name was inserted in the ppu? Or does it use the system.o
if it can not find the shared lib? (because in system.ppu it's named
imprtl)
I then added -k-lrtl -st to FPC's command line and removed the
system.o from the test_link.res. Calling test_ppas.sh resulted in
the following output:
output begin
Linking test
ld: warning: test_link.res contains output sections; did you forget -T?
test.o: In function `main':
test.pas:(.text+0xa): undefined reference to `FPC_INITIALIZEUNITS'
test.pas:(.text+0x27): undefined reference to `FPC_IOCHECK'
test.pas:(.text+0x33): undefined reference to `FPC_IOCHECK'
An error occurred while linking test
output end
Those two symbols are indeed missing in librtl.so (but
FPC_LIBINITIALIZEUNITS is included), so something didn't work quite
right here.
So much for my findings. I hope you find it interesting. :)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test: compiling packages
Hi Sven! Am 19.09.2010 13:49, schrieb Sven Barth: and the following for Windows: pp -Twin32 -Fuunits/i386-win32 rtl.ppk I tried this with my 64 bit-head version of fpc, but it failed to produce any output except an .a and an .o file. fpc -Twin64 -Fuunits\x86_64-win64 rtl.ppk unknown: 12 unknown: 12 rtl.ppk(7) Error: PPU is already in a library : C:\source\fpcwilli\units\x86_64-win64\rtl\system.ppu rtl.ppk(7) Error: Multiple defined symbol _DLLMainCRTStartup rtl.ppk(7) Error: Undefined symbol: PASCALMAIN rtl.ppk(7) Fatal: There were 3 errors compiling module, stopping Fatal: Compilation aborted Error: C:\source\fpcwilli\bin\x86_64-win64\ppcx64.exe returned an error exitcode (normal if you did not specify a source file to be compiled) So I guess there's more work to be done on the win64 target: I will look into this once I have a debug build of trunk (see my other mail) on my disk. The Windows package is created as rtl.dll and the Linux one as librtl.so, although I expected rtl.ppl for Win32 and librtl.ppl for Linux or even rtl-2.5.1.ppl and librtl-2.5.1.ppl on the respective platforms. So this needs to be fixed as well. True we also need to implemente the $LIBSUFFIX and $LIBVERSION (probably also $DESCRIPTION) compiler switches.. So much for my findings. I hope you find it interesting. :) Thanks a lot. I found the differences between Linux, Windows32 and Windows64 (my own build) interesting to see. Yep, there's quite some work ahead.. That said, I'll probably concentrate on Win64 first as I am running Windows 7 x64. BTW: Is it possible to get a separate branch in the svn repo for hacking on the package feature? Or should source-code patches be posted to fpc-devel before directly going into trunk? Cheers, Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test cases in FPC - how to they work?
hi, I'm working on Linux support for code page enabled string types (branch cpstrnew). In general, is their a special way that the test projects in 'fpc/tests/test/*' should be run? Sorry, I'm used to FPCUnit or DUnit2 test cases which gives a clear indication if a test passed or failed. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test cases in FPC - how to they work?
On 03 Dec 2009, at 14:31, Graeme Geldenhuys wrote: In general, is their a special way that the test projects in 'fpc/tests/test/*' should be run? From fpc/tests/readme.txt: *** Writing a test -- A test should have a name on the form t*.pp, to be recognized as a test. It should return 0 on success, any other value indicates failure. *** The It should return refers to the program exit code. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test cases in FPC - how to they work?
Jonas Maebe wrote: A test should have a name on the form t*.pp, to be recognized as a test. It should return 0 on success, any other value indicates failure. Ah thanks! And that would explain the lines with Halt(1) at the end of those test projects :-) No idea how I missed that. :-( Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test
Hi, Just subscribed, testing system. Regards, Nino ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test
fpc...@silvermono.co.za wrote: Hi, Just subscribed, testing system. Welcome Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test
Just a test. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test fpcres
Hi
I've check tests for Test suite results for test file
test/units/system/tres2.pp
but I nottice that different fpcres is use to compile
in trunk is ver 2.0{ Note: This program is not the old fpcres by
Simon Kissel }
but is use old :
Log of 35027:
Error: Unknown command-line parameter : -a
fpcres - Free Pascal Resource to ELF object compiler
Part of the Free Pascal and CrossFPC distributions
Copyright (C) 2005 Simon Kissel
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test
it worked! 2008/6/17 Vincent Snijders [EMAIL PROTECTED]: ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test
___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test, please ignore
___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test, please ignore
Sorry again, mailman makes trouble. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test, please ignore
___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test, please ignore
test, please ignore ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test
test ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test
test ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test, please ignore
___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel]test
Hiya, This is a test from one of thhe system-administrator of deadlock.et.tudelft.nl to test if the new mailconfiguration is working. You can ignore this message. Greetings, Erik Noort member of the systemadministrator team of deadlock.et.tudelft.nl ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
