[fpc-devel] Forwarded message about FPC status
Hi, Any FPC developer willing to comment on the status of some of these issues (that have been years overdue)? Original Message Subject: Re: [MSEide-MSEgui-talk] MSEide+MSEgui 2.8.4 Date: Mon, 17 Dec 2012 08:57:15 +0100 From: John Doe 1 To: mseide-msegui-t...@lists.sourceforge.net On Saturday 15 December 2012 18:19:24 John Doe 2 wrote: On 14/12/12 20:15, John Doe 1 wrote: This probably is the last version which depends on FPC-FCL. I often feel like doing the same. Hell, sometimes even replacing the RTL. I already have a slimmed down SysUtils and Classes unit in a private branch. It seems to me, main target of FPC development today is compatibility to the modern Delphi language constructs, I don't want to go this route.And we need more flexibility, I can't fight days or weeks with Michael and Marco for every little change which is not on Lazarus or their own benefit.Ouh, and there still is no unicode support for resource strings, no official statement how unicode will be implemented in RTL, the compiler becomes slower and slower, smart linking MSEide on 64 bit Linux is not possible with 2GB ram, still no Delphi-like packages... Sad. John Doe 1 --[ end ]--- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 17.12.2012 10:36, schrieb Graeme Geldenhuys: It seems to me, main target of FPC development today is compatibility to the modern Delphi language constructs, I don't want to go this route. And? Some people want to have these features (especially I want generic, I want helpers, I want closures and I want the extented RTTI, so I implement them!). If you don't need them, don't use them. We try to implement them in a way that the compiler's performance (parsing speed, etc.) or the executable size (to be implemented extended RTTI) is not influenced negatively too much. But somewhere one has to pay for it. Somewhen in the future we'll need to refactor the compiler a bit (maybe add multithreading support) and then things should be better again... And we need more flexibility, I can't fight days or weeks with Michael and Marco for every little change which is not on Lazarus or their own benefit. I don't know what flexibility you are talking about, but including everything in the RTL is not the answer. One needs to judge what can be made part of it and what not, because otherwise it will just be a chaos (yes, it already is a bit, mostly because of backwards compatibility). Ouh, and there still is no unicode support for resource strings, Currently not planned AFAIK. But maybe it's also not really necessary if the unit containing the resourcestrings is compiled in UTF8 format (I don't know though, this is not a topic I'm familiar with). no official statement how unicode will be implemented in RTL, There is no official statement, because we don't know ourselves really where we want to go and everytime the discussions comes up it dies down a bit later without much results... the compiler becomes slower and slower, I commented on this at the top already smart linking MSEide on 64 bit Linux is not possible with 2GB ram, Linking is a problem of ld, not of Free Pascal. ld was not designed for the workload we put on it (especially regarding smart linking). You could try however if the new internal ELF linker solves this problem for you (I don't know whether it already supports smart linking; this is something that Sergei should answer) still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can make use of it and already the difference regarding procedure name resolution between Windows and Unix can cause headaches... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi's current TThread implementation
On 12/16/2012 05:41 PM, Sven Barth wrote: Please note that (as I already described in another message) TThread.Queue now is an officially documented function (using overlay procedures with alternate parameters). Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
17.12.2012 13:55, Sven Barth пишет: smart linking MSEide on 64 bit Linux is not possible with 2GB ram, Linking is a problem of ld, not of Free Pascal. ld was not designed for the workload we put on it (especially regarding smart linking). You could try however if the new internal ELF linker solves this problem for you (I don't know whether it already supports smart linking; this is something that Sergei should answer) The problem here is that smartlinking is still being done with archives (.a) on x86 Linux targets, while ld's preferred mode of operation is section-based smartlinking. Switching to section-based smartlinking will probably reduce memory requirements to acceptable level. However, FPC does not handle exported symbols correctly and they get lost if section-based smartlinking is used. The internal linker of course supports smartlinking, moreover it is not sensitive to the mentioned exported symbol issue. Regards, Sergei. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi's current TThread implementation
Am 17.12.2012 11:23 schrieb Michael Schnell mschn...@lumino.de: On 12/16/2012 05:41 PM, Sven Barth wrote: Please note that (as I already described in another message) TThread.Queue now is an officially documented function (using overlay procedures with alternate parameters). I know that (partly from your mail), but this does not explain some of the things they are doing in the background (like what happens with exceptions raised inside a queued function) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi's current TThread implementation
On 12/17/2012 12:32 PM, Sven Barth wrote: I know that (partly from your mail), but this does not explain some of the things they are doing in the background (like what happens with exceptions raised inside a queued function) I see. Interesting stuff :-) . Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Sven Barth schrieb: still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can make use of it and already the difference regarding procedure name resolution between Windows and Unix can cause headaches... We should wait for and explore how the multi-target Delphi handles that. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mips-linux and mipsel-linux snapshots available
Hi Sergei and Mark, 16.12.2012 12:41, Sergei Gorelkin: [...] This was caused by insufficient alignment of Double-typed temp variables, fixed in r23146. Moreover, it appeared that function UnixToWinAge wasn't doing anything useful since year 2005, so it was removed in r23145, making FindFirst/FindNext routines somewhat faster (and able to run without FPU). Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll be able to reproduce it, too. This is to remind you guys that if you wish to do some testing/debugging/etc on a real mips device via ssh, two debian mips boxes (big and little endian) with plenty of disk space are running here 24/7 for exactly that purpose. They are not much loaded and I can create some account(s) for you any time. Nikolai Regards, Sergei ___ 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] Forwarded message about FPC status
On 17/12/12 13:06, Hans-Peter Diettrich wrote: We should wait for and explore how the multi-target Delphi handles that. Probably not even implemented, because Delphi IDE is Windows only - and there are no plans to make a cross-platform IDE by Embarcadero. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 17.12.2012 14:06, schrieb Hans-Peter Diettrich: Sven Barth schrieb: still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can make use of it and already the difference regarding procedure name resolution between Windows and Unix can cause headaches... We should wait for and explore how the multi-target Delphi handles that. No. We need to think about this ourselves as we support more targets than Delphi ever will support. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mips-linux and mipsel-linux snapshots available
On Mon, 17 Dec 2012, Nikolai Zhubr wrote: Hi Sergei and Mark, 16.12.2012 12:41, Sergei Gorelkin: [...] This was caused by insufficient alignment of Double-typed temp variables, fixed in r23146. Moreover, it appeared that function UnixToWinAge wasn't doing anything useful since year 2005, so it was removed in r23145, making FindFirst/FindNext routines somewhat faster (and able to run without FPU). Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll be able to reproduce it, too. This is to remind you guys that if you wish to do some testing/debugging/etc on a real mips device via ssh, two debian mips boxes (big and little endian) with plenty of disk space are running here 24/7 for exactly that purpose. They are not much loaded and I can create some account(s) for you any time. The FPC team has a MIPS device (longsoon?) available. It's currently switched off, but can be switched on at any time. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Sven Barth schrieb: Am 17.12.2012 14:06, schrieb Hans-Peter Diettrich: Sven Barth schrieb: still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can make use of it and already the difference regarding procedure name resolution between Windows and Unix can cause headaches... We should wait for and explore how the multi-target Delphi handles that. No. We need to think about this ourselves as we support more targets than Delphi ever will support. Nonetheless it would be wise to wait for an Embarcadero solution. They might invent a new cross-platform model for their packages, in which case we ended up in yet another package model. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 17.12.2012 16:20, schrieb Hans-Peter Diettrich: Sven Barth schrieb: Am 17.12.2012 14:06, schrieb Hans-Peter Diettrich: Sven Barth schrieb: still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can make use of it and already the difference regarding procedure name resolution between Windows and Unix can cause headaches... We should wait for and explore how the multi-target Delphi handles that. No. We need to think about this ourselves as we support more targets than Delphi ever will support. Nonetheless it would be wise to wait for an Embarcadero solution. They might invent a new cross-platform model for their packages, in which case we ended up in yet another package model. From what I see so far of the route that Embarcadero takes (complete reimplementation of compiler, sudden appearence of type helpers and things like zero based strings) I predict that we'll reach a point in the near(!) future where we won't (be able to) follow Delphi's lead anymore. And thus I don't think that we'll need to wait for Embarcadero for this. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mips-linux and mipsel-linux snapshots available
17.12.2012 19:12, michael.vancann...@wisa.be: [...] The FPC team has a MIPS device (longsoon?) available. It's currently switched off, but can be switched on at any time. Ah, ok. That's good news. If it is longsoon then it must be much faster than mine. (Though IIRC it only exists in little endian variant). Anyway, I'll still keep my boxes up for now. Nikolai Michael. ___ 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] Forwarded message about FPC status
On 17/12/12 15:29, Sven Barth wrote: I predict that we'll reach a point in the near(!) future where we won't (be able to) follow Delphi's lead anymore. And what a good day that will be. FPC will can innovate again. Delphi hasn't been leading for years, and Embarcadero is milking a dead cow!!! Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Graeme Geldenhuys wrote: On 17/12/12 15:29, Sven Barth wrote: I predict that we'll reach a point in the near(!) future where we won't (be able to) follow Delphi's lead anymore. And what a good day that will be. FPC will can innovate again. Delphi hasn't been leading for years, and Embarcadero is milking a dead cow!!! Embarcadero has a dead cow propped up in the barn, and is telling everybody that they still milk it. Summed up eloquently by Ms Stob http://www.theregister.co.uk/2012/12/11/verity_stob_sons_of_kahn/ -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Sven Barth wrote: From what I see so far of the route that Embarcadero takes (complete reimplementation of compiler, sudden appearence of type helpers and things like zero based strings) I predict that we'll reach a point in the near(!) future where we won't (be able to) follow Delphi's lead anymore. And thus I don't think that we'll need to wait for Embarcadero for this. For what my opinion is worth, I believe that we can learn from what happened when Clarion bought JPI/TopSpeed: they were interested in owning the technology rather than in ongoing sales of the compilers etc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Building the Android branch
Hello together! I'm currently testing the Android branch and I've already reached a problem when trying to build it. I've downloaded the current Android NDK r8c and then tried to run the following command line: make all OS_TARGET=android CPU_TARGET=arm CROSSBINDIR=/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin BINUTILSPREFIX=arm-linux-androideabi- OPT=-dFPC_ARMEL CROSSOPT=-CpARMv6 -Cfsoft This works until the process reaches the CHM package where it wants to compile chmls. The compiler then returns with a linker error when executing the following command (reported by fpmake): /mnt/data/source/fpc/fpc-android/compiler/ppcrossarm -Tandroid -FEchm/bin/arm-android -FUchm/units/arm-android -Fu/mnt/data/source/fpc/fpc-android/rtl/units/arm-android -Fu/mnt/data/source/fpc/fpc-android/packages/fcl-xml/units/arm-android -Fu/mnt/data/source/fpc/fpc-android/packages/fcl-base/units/arm-android -Tandroid -Parm -XParm-linux-androideabi- -Xr -Ur -Xs -O2 -n -Fu/mnt/data/source/fpc/fpc-android/rtl/units/arm-android -FD/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin -dFPC_ARMEL -darm -dRELEASE -CpARMv6 -Cfsoft -viq chm/src/chmls.lpr When I run that command manually from within the packages directory I get the following output: === output begin === (1002) Target OS: Android for ARMEL (3104) Compiling chm/src/chmls.lpr (9009) Assembling chmls (9015) Linking chm/bin/arm-android/chmls /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:1:22: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:2:67: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:3:40: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:4:41: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:5:54: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:47:13: ignoring command OPTION; OPTION is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:52:29: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:52:50: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:52:75: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmls.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmreader.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmbase.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmsitemap.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-base/units/arm-android/contnrs.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error:
[fpc-devel] Re: Building the Android branch
Hi, On Mon, 2012-12-17 at 21:45 +0100, Sven Barth wrote: Hello together! I'm currently testing the Android branch and I've already reached a problem when trying to build it. I've downloaded the current Android NDK r8c and then tried to run the following command line: make all OS_TARGET=android CPU_TARGET=arm CROSSBINDIR=/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin BINUTILSPREFIX=arm-linux-androideabi- OPT=-dFPC_ARMEL CROSSOPT=-CpARMv6 -Cfsoft This works until the process reaches the CHM package where it wants to compile chmls. The compiler then returns with a linker error when executing the following command (reported by fpmake): /mnt/data/source/fpc/fpc-android/compiler/ppcrossarm -Tandroid [...] /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:1:22: ignoring SEARCH_DIR; [...] The problem is that the android 8c ndk uses the GOLD linker by default. GOLD is not compatible with fpc. E.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620815 Can you retry with an older ndk (GOLD is new to the 8c ndk). Alternatively, in ndk-dir/[...]/arm-linux-androideabi-4.6/prebuilt/ arm-linux-androideabi-ld there is a copy of the arm-linux-androideabi-ld.gold executable. There is an arm-linux-androideabi-ld.bfd there as well, so just overwrite arm-linux-androideabi-ld with the latter (or symlink to the bfd one). Another thing, you need to add the platforms/android-XX/arch-arm/usr/lib directory to the library search paths using -Fl in the CROSS_OPT. Otherwise the compiler won't find the C library later. There is a new issue I have never seen before that fpdoc (actually cwstring) now wants to link with libiconv which is not available on Android (you can build it yourselves though). Simply excluding it from the android build would fix that. Maybe you could have a look? Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building the Android branch
On 18.12.2012 00:10, Thomas Schatzl wrote: Hi, On Mon, 2012-12-17 at 21:45 +0100, Sven Barth wrote: Hello together! I'm currently testing the Android branch and I've already reached a problem when trying to build it. I've downloaded the current Android NDK r8c and then tried to run the following command line: make all OS_TARGET=android CPU_TARGET=arm CROSSBINDIR=/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin BINUTILSPREFIX=arm-linux-androideabi- OPT=-dFPC_ARMEL CROSSOPT=-CpARMv6 -Cfsoft This works until the process reaches the CHM package where it wants to compile chmls. The compiler then returns with a linker error when executing the following command (reported by fpmake): /mnt/data/source/fpc/fpc-android/compiler/ppcrossarm -Tandroid [...] /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:1:22: ignoring SEARCH_DIR; [...] The problem is that the android 8c ndk uses the GOLD linker by default. GOLD is not compatible with fpc. E.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620815 Can you retry with an older ndk (GOLD is new to the 8c ndk). Alternatively, in ndk-dir/[...]/arm-linux-androideabi-4.6/prebuilt/ arm-linux-androideabi-ld there is a copy of the arm-linux-androideabi-ld.gold executable. There is an arm-linux-androideabi-ld.bfd there as well, so just overwrite arm-linux-androideabi-ld with the latter (or symlink to the bfd one). Yes, that was the problem -.- Maybe we should somewhen investigate what it would mean to support GOLD... or we concentrate to get the internal linker for Android working :D Another thing, you need to add the platforms/android-XX/arch-arm/usr/lib directory to the library search paths using -Fl in the CROSS_OPT. Otherwise the compiler won't find the C library later. Correct... Done... There is a new issue I have never seen before that fpdoc (actually cwstring) now wants to link with libiconv which is not available on Android (you can build it yourselves though). Simply excluding it from the android build would fix that. Maybe you could have a look? Excluding fpdoc itself is a bit tricky as it's listed in the basic dirs of utils/Makefile.fpc and thus is built for every target for which utils is build... for me locally I just added Android to the NOUTILSTARGET of the base Makefile(.fpc). Maybe the real solution would be the Unicode String Manager posted here: http://bugs.freepascal.org/view.php?id=22909 The discussion about it's inclusion died down after a mail was sent to the Unicode consortium where we asked about some legal issues regarding the Unicode tables... they seem to have never answered though... So building works so far, but the next problem is crossinstall... even after I do a normal install for my host system I get the following when trying to do a crossinstall for Android: === output begin === make install CROSSINSTALL=1 make[1]: Entering directory `/mnt/data/source/fpc/fpc-android' make installbase FPC=/mnt/data/source/fpc/fpc-android/compiler/ppcrossarm ZIPDESTDIR=/mnt/data/source/fpc/fpc-android FPCMAKE=fpcmake make[2]: Entering directory `/mnt/data/source/fpc/fpc-android' /usr/bin/install -m 755 -d /mnt/data/source/fpc/fpc-android-install/lib/fpc/2.7.1 /usr/bin/install -m 755 -d /mnt/data/source/fpc/fpc-android-install/bin make compiler_install FPC=/mnt/data/source/fpc/fpc-android/compiler/ppcrossarm ZIPDESTDIR=/mnt/data/source/fpc/fpc-android FPCMAKE=fpcmake make[3]: Entering directory `/mnt/data/source/fpc/fpc-android' make -C compiler install make[4]: Entering directory `/mnt/data/source/fpc/fpc-android/compiler' make -C utils install make[5]: Entering directory `/mnt/data/source/fpc/fpc-android/compiler/utils' make[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/compiler/utils' /usr/bin/install -m 755 -d /mnt/data/source/fpc/fpc-android-install/lib/fpc/2.7.1 /usr/bin/install -c -m 755 ppcrossarm /mnt/data/source/fpc/fpc-android-install/lib/fpc/2.7.1/ppcrossarm make[4]: Leaving directory `/mnt/data/source/fpc/fpc-android/compiler' make[3]: Leaving directory `/mnt/data/source/fpc/fpc-android' make rtl_install FPC=/mnt/data/source/fpc/fpc-android/compiler/ppcrossarm ZIPDESTDIR=/mnt/data/source/fpc/fpc-android FPCMAKE=fpcmake make[3]: Entering directory `/mnt/data/source/fpc/fpc-android' make -C rtl install make[4]: Entering directory `/mnt/data/source/fpc/fpc-android/rtl' make -C android all make[5]: Entering directory `/mnt/data/source/fpc/fpc-android/rtl/android' make[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl/android' fpcmake -p -Tarm-android Makefile.fpc Processing Makefile.fpc Error: No targets set make[4]: *** [fpc_install] Fehler 1 make[4]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl' make[3]: *** [rtl_install] Fehler 2 make[3]: Leaving
