Re: [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Ivan Bobyr said: But it's difficult to object to the below Martin's statement: -- Please change TDataset.Bookmark to tbytes = array of byte if you absolutely need to change it in fixes_2_6 so we have a bookmark type with automatic memory management again. That's what he _first_ said. Later he didn't want to change anything at all. Currently in 2.7.1 this (TBytes) is already done, I'm waiting for (testing)feedback before merging. PS: If the main advantage of FPC over C/C++ is its automatic memory management then we should obviously use it, correct ? Not all problems in programming are related to (automatic or not) memory management :-) Calling a virtual(!) method when a bookmark is no longer needed allows to do other things too, like releasing something with db handles, and allows descendents of TDataset to do such things. But apparently I was mistaken about this (or at least how recent freebookmark use was in the Delphi community). So let's just push it to the current Delphi situation as quickly as reasonably possible, and lets forget about the whole thing. As far as the C/C++ vs Pascal comparison goes, FPC has as advantage over mandatory GC languages like Java that you are not chained to automatic memorymanagement. So use of it must be scrutinized. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
marcov wrote on Fri, 27 Apr 2012: In our previous episode, Ivan Bobyr said: But it's difficult to object to the below Martin's statement: -- Please change TDataset.Bookmark to tbytes = array of byte if you absolutely need to change it in fixes_2_6 so we have a bookmark type with automatic memory management again. That's what he _first_ said. Later he didn't want to change anything at all. Well, in fairness he did add if you absolutely need to change it in fixes_2_6 the first time, so I think the fact that he prefers no change at all to this API did not change. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] New arm/android target available in svn branch
recently I added preliminary arm/android support as official target for fpc. The changes are available in the http://svn.freepascal.org/svn/fpc/branches/targetandroid/ branch. How to compile: --- from the command line, e.g. by issuing make zipinstall FPC=host fpc compiler OS_TARGET=android CPU_TARGET=arm CROSSOPT=-Cfsoft BINUTILSPREFIX=prefix-to-android-ndk-as-ld you should get a nice archive with your cross compiler after completion. Before that you might need to create a new fpcmake tool by e.g. building a normal zipinstall to be used during building the crosscompiler (or native compiler) and put it into the path. Usage notes: - while the compiler should now be appropriately prepared for the target, the rtl likely still contains a few bugs; I successfully compiled and ran some shared libraries and created Android (sdl/OpenGL based) app generated by it. - no special packaging support at the moment, you have to do that using the ndk by replacing .so's. - no Android API header translations included in the rtl - while it is able to generate standalone executables, they have not been tested - usual disclaimer, generated code may jump in your face etc. Developer notes --- - the compiler does NOT define LINUX during compilation! It defines UNIX and ANDROID though. This will likely not change. (Background: Android is not completely Linux compatible, e.g. a few syscalls and default library functions e.g. in pthreads, ... are missing, and it generally behaves different in a few ways. This makes the amount of defines manageable by avoiding if defined(linux) and not defined(android). Actually, the list of things that are different is only growing) - the current interface to the OS uses syscalls, not the bionic libc. This default might change in the future at least for shared libraries, because at the moment this means that environment variables are not available (envp) for them. - shared libraries do not have argc/argv/envp available (i.e. set to 0 or nil) because of Android. - the selection of compiled packages is mostly driven by what libraries are shipped by default on Android, i.e. not much. I might have missed one or two though. - comments, questions and patches are much appreciated - I do have to warn you though that I usually do not have much time and equipment available for a lot of testing, but I am available to reviewing and committing of patches. Note that probably a lot of workarounds for the arm/linux compiler that have previously been required for getting arm/android executables to work are not needed any more. Anyway, have fun, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
On Friday 27 April 2012 11:33:50 Jonas Maebe wrote: marcov wrote on Fri, 27 Apr 2012: In our previous episode, Ivan Bobyr said: But it's difficult to object to the below Martin's statement: -- Please change TDataset.Bookmark to tbytes = array of byte if you absolutely need to change it in fixes_2_6 so we have a bookmark type with automatic memory management again. That's what he _first_ said. Later he didn't want to change anything at all. Well, in fairness he did add if you absolutely need to change it in fixes_2_6 the first time, so I think the fact that he prefers no change at all to this API did not change. Correct. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
On Thu, Apr 26, 2012 at 5:35 AM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On 26 April 2012 06:58, Martin Schreiber mse00...@gmail.com wrote: I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in FPC 2.7.1 only. Macro wants feedback, well here is some... I fully agree with Martin. Please revert such code breaking changes in the STABLE 2.6.x release! When I (and many other FPC users) update our 2.6.x to the latest fixes commits, we don't expect breakage! Breakages belong in TRUNK only. +1 IMHO even new things and improvements would be welcome, but not break the old things. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] OpenBsd cross compiler
Hi Leonardo, -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Leonardo M. Ramé Envoyé : jeudi 26 avril 2012 21:10 À : FPC developers' list Objet : [fpc-devel] OpenBsd cross compiler Hi, I usually create Win32 targets using this: make crossinstall OS_TARGET=win32 CPU_TARGET=i386 PP=/home/leonardo/Desarrollo/fpc/i386-linux-ppc386 Now I want to create an OpenBSD cross compiler, so I just replaced win32 by openbsd: Yes, but you do need cross-binutils for openbsd! The problem is that current GNU Binutils source do not generate correct objects/executables for openbsd. Which means that you need to get an openbsd specific binutils source install it, and configure it for the target you are interested in: I checked the internet, and it seems to be difficult to fond. Thus I added it to ftp://ftp.freepascal.org/pub/fpc/contrib/cross/openbsd/ 1) Downloaded ftp://ftp.freepascal.org/pub/fpc/contrib/cross/openbsd/binutils-openbsd-2.15 .tar.gz file. 2) Untar it tar -xvzf binutils-openbsd-2.15.tar.gz 3) Create build directory: mkdir build-cross-i386-openbsd cd build-cross-i386-openbsd 4) Run configure for that target ../binutils-4.9/configure --target=i386-pc-openbsd --program-prefix=i386-openbsd- (That's what I used on mingw32, but to compile on mingw you also need to apply the patch that I added in the same directory on ftp server). 5) Compile and install everything: make all-gas all-binutils all-ld make install-gas install-binutils install-ld prefix=PATH/TO/WHERE/YOU/WANT/IT This should install i386-openbsd-as i386-openbsd-ld and a few more into PATH/TO/WHERE/YOU/WANT/IT/bin directory Note that I didn't use the same procedure on mingw (because I wanted to get binaries that did not depend on any mingw specific DLLs) make crossinstall OS_TARGET=openbsd CPU_TARGET=i386 PP=/home/leonardo/Desarrollo/fpc/i386-linux-ppc386 But the linker is not found. This is the error I get: make[5]: se ingresa al directorio «/home/leonardo/Desarrollo/fpc/rtl/openbsd» /bin/mkdir -p /home/leonardo/Desarrollo/fpc/rtl/units/i386-openbsd i386-openbsd-as -o /home/leonardo/Desarrollo/fpc/rtl/units/i386- openbsd/prt0.o i386/prt0.as make[5]: i386-openbsd-as: No se encontró el programa make[5]: *** [prt0.o] Error 127 make[5]: se sale del directorio «/home/leonardo/Desarrollo/fpc/rtl/openbsd» make[4]: *** [openbsd_all] Error 2 make[4]: se sale del directorio «/home/leonardo/Desarrollo/fpc/rtl» make[3]: *** [rtl] Error 2 make[3]: se sale del directorio «/home/leonardo/Desarrollo/fpc/compiler» make[2]: *** [cycle] Error 2 make[2]: se sale del directorio «/home/leonardo/Desarrollo/fpc/compiler» make[1]: *** [compiler_cycle] Error 2 make[1]: se sale del directorio «/home/leonardo/Desarrollo/fpc» make: *** [build-stamp.i386-openbsd] Error 2 Is there an i386-openbsd-as linker?. Where can I find it. i386-openbsd-as is the assembler, not the linker i386-openbsd-ld is the linker. BTW. I'm on Linux x86_64 (Ubuntu 11.10). You could repeat the steps for x86_64-openbsd target by simply using --target=x86_646pc-openbsd Hoping the above will help, Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FreePascal Git Repo and 2_6 branch
I am wondering if Graeme can update his FreePascal git mirror to include the 2_6 branches. Thanks David Jenkins ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
