Re: [fpc-devel] Forwarded message about FPC status
Graeme Geldenhuys wrote: This is why I decided to diversify, and why I will once again turn my attention to Java (not JavaScript-that-is-the-assembly-language-of-the-internet). Java seems the sensible route to go, for long term employment. There is a very healthy Java industry (stacks of jobs), fantastic tools (IDE's, debugger etc), and the rate of pay is fantastic too. We have SPARC-based systems manufactured by Sun here, and I am dismayed at the extent to which /somebody/ has been leaning heavily on web sites who up till now have got away with harbouring copies of system manuals etc. Right now I'd be extremely wary about pinning my livelihood to Java, lest Oracle succeed in locking it down as their personal property. I can't suggest any alternative, but I'd suggest watching IBM's position carefully since they're undoubtedly thinking the same thing. -- 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] Re: Building the Android branch
Hi, On Tue, 2012-12-18 at 07:30 +0100, Sven Barth wrote: On 18.12.2012 00:10, Thomas Schatzl wrote: Hi, On Mon, 2012-12-17 at 21:45 +0100, Sven Barth wrote: 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: [...] The problem is that the android 8c ndk uses the GOLD linker by default. GOLD is not compatible with fpc. [...] 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 On i386-android I guess you can simply use the i386-linux internal linker. Not sure about how much work an arm-linux internal linker would be (if there isn't). 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? Actually, I just tried, make clean all crosszipinstall works with a recent 2.7.1 snapshot except that you need to patch the _FPC_libc_start method in rtl/linux/i386/si_c.inc with the latest version. I.e. basically, the targetandroid branch needs merging with the latest trunk to work again. Not sure why, but with trunk, utils won't be compiled in a crosszipinstall any more automatically. It does not make sense anyway to compile target binaries for them anyway since you're going to install on the host. Bootstrapping with 2.6.0 not work. Don't remember exactly why, but this is just another reason then. The missing libiconv also prevents making a zipinstall for android-arm at the moment; as mentioned, I think it did not have that problem earlier. I remember that this already worked at some point. Eventually this error slipped through when merging trunk to that branch last time. Either disabling compilation of fpdoc or simply using the bootstrap tools on the target (fpcmake, data2inc and ppcarm compile) to complete a build on the target should be fine. If you disable the WPO cycle on these devices, and using all threads/cores you can get, making a zipinstall does not take that long on current arm machines. Iirc the fpc arm-linux build machine (quad core, 1.4Ghz) takes around 12 minutes to generate a full snapshot (with WPO cycle). Most time is taken by the serial compiler cycle. 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... This would be a good idea, but is orthogonal to the android branch. 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[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl/android' fpcmake -p -Tarm-android Makefile.fpc Processing Makefile.fpc Error: No targets set [...] Use of wrong fpcmake. What I typically do, since I'm often working with different fpc versions/branches at the same time, is not have a global fpc install. I simply copy fpcmake (in utils/fpcm), data2inc (in utils) and the ppc386 bootstrap snapshot compiler into a directory and add that directory into the path. So compile the branch once with the 2.7.1 compiler (after applying above patch, e.g. make zipinstall PP=...) to get these bootstrap tools, put those files into a directory, put that directory into the path and use them to compile the targetandroid branch. This is of course a totally unsupported way to use fpc and you're on your own when doing so :-P ymmv. Hth, Thomas ___ 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 12/17/2012 03:44 PM, Graeme Geldenhuys wrote: 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 - IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus, as adding a source package and recompiling does the trick just as well. What does make sense are Delphi like pre-compiled dynamically linked (Runtime)-packages, allowing for creating plugins. -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
On 12/17/2012 03:55 PM, Sven Barth wrote: No. We need to think about this ourselves as we support more targets than Delphi ever will support. Even cross-platform runtime packages might make sense (e.g. linking a native plugin package to an Android/Java Program) Something I could (supposedly in vain) dream of: Remote plugin-packages attachable via TCP/IP. -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
On 12/17/2012 04:29 PM, 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. I suppose Unicode strings could be done better in a (slightly) incompatible way. (e.g. allowong for as well decently code-agnostic (never converted) RawByte, RawWord and RawDWord strings as for decently dynamically coded Flexy-Strings that are auto-converted when necessary), with a decent definition of what happens when Normal (predefined coding) String Types, Raw and Flexi strings are used in combination. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building the Android branch
Am 18.12.2012 11:09, schrieb Thomas Schatzl: 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? Actually, I just tried, make clean all crosszipinstall works with a recent 2.7.1 snapshot except that you need to patch the _FPC_libc_start method in rtl/linux/i386/si_c.inc with the latest version. I.e. basically, the targetandroid branch needs merging with the latest trunk to work again. Or you could just merge to trunk... might result in a better test user coverage as well :) Not sure why, but with trunk, utils won't be compiled in a crosszipinstall any more automatically. It does not make sense anyway to compile target binaries for them anyway since you're going to install on the host. AFAIK that was disabled on purpose some time ago exactly because of that reason. 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[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl/android' fpcmake -p -Tarm-android Makefile.fpc Processing Makefile.fpc Error: No targets set [...] Use of wrong fpcmake. What I typically do, since I'm often working with different fpc versions/branches at the same time, is not have a global fpc install. I simply copy fpcmake (in utils/fpcm), data2inc (in utils) and the ppc386 bootstrap snapshot compiler into a directory and add that directory into the path. So compile the branch once with the 2.7.1 compiler (after applying above patch, e.g. make zipinstall PP=...) to get these bootstrap tools, put those files into a directory, put that directory into the path and use them to compile the targetandroid branch. This is of course a totally unsupported way to use fpc and you're on your own when doing so :-P ymmv. I now simply replaced my 2.6.0 fpcmake with one compiled from the Android branch and were happy to go :) So I (this time on Windows) managed to compile and install the branch and now just need to check whether it will work... Now I just need to test whether the Android LCL test application/library works... Thank you so far :D Regards, Sven ___ 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 18/12/12 12:19, Michael Schnell wrote: IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus, as adding a source package and recompiling does the trick just as well. Tell that to component developers and companies like Devx, TMS etc! With the current way things work, there is 0% chance of getting a trial version of any component. 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
[fpc-devel] Re: Building the Android branch
Hi, On Tue, 2012-12-18 at 13:48 +0100, Sven Barth wrote: Am 18.12.2012 11:09, schrieb Thomas Schatzl: 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? Actually, I just tried, make clean all crosszipinstall works with a recent 2.7.1 snapshot except that you need to patch the _FPC_libc_start method in rtl/linux/i386/si_c.inc with the latest version. I.e. basically, the targetandroid branch needs merging with the latest trunk to work again. Or you could just merge to trunk... might result in a better test user coverage as well :) :) Maybe I have time to clean up and propose a patch in January. I now simply replaced my 2.6.0 fpcmake with one compiled from the Android branch and were happy to go :) So I (this time on Windows) managed to compile and install the branch and now just need to check whether it will work... Now I just need to test whether the Android LCL test application/library works... Thank you so far :D I never tried the LCL, but with some hacking of android makefiles I managed to create and run some opengl demo application. Use the NDK bindings on lazarus-ccr; just looked, the bindings are still there, but that example application seems to be gone. I heard other people were successful with a hacked arm/linux compiler before that branch started. Of course, console apps like the compiler to do e.g. a make cycle also worked last time I tried. Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building the Android branch
Am 18.12.2012 14:15, schrieb Thomas Schatzl: I now simply replaced my 2.6.0 fpcmake with one compiled from the Android branch and were happy to go :) So I (this time on Windows) managed to compile and install the branch and now just need to check whether it will work... Now I just need to test whether the Android LCL test application/library works... Thank you so far :D I never tried the LCL, but with some hacking of android makefiles I managed to create and run some opengl demo application. Use the NDK bindings on lazarus-ccr; just looked, the bindings are still there, but that example application seems to be gone. I heard other people were successful with a hacked arm/linux compiler before that branch started. Of course, console apps like the compiler to do e.g. a make cycle also worked last time I tried. I successfully compiled the lcl-customdrawn example library, but the Java side code does not like the idea of being compiled -.- I'll need to look into this... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
In our previous episode, Graeme Geldenhuys said: IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus, as adding a source package and recompiling does the trick just as well. Tell that to component developers and companies like Devx, TMS etc! With the current way things work, there is 0% chance of getting a trial version of any component. They could deliver ppu's and .o's. ___ 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 18/12/12 13:26, Marco van de Voort wrote: They could deliver ppu's and .o's. True, but widely untested. As a previous conversation from a few month back ended... it should work in theory. Also Lazarus Packages are designed to work with source only. There is no option to install .ppu's and .o's in Lazarus IDE. But this is another issue, best left to be discussed in the Lazarus mailing list. 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] utf8 in 2.6.0
On 15.12.2012 21:35, Martin wrote:
I am trying to figure out how to do that, or what I do wrong. I found
a page about $codepage, but it did not help
http://wiki.freepascal.org/LCL_Unicode_Support
I didnt find the fpc specific page, if exists (I suspect it does)
I am calling a function function Foo(A:string) {$mode objfpc}{$H+}
I call it with a constant, that contains an german umlaut. Checked
with a hex editor, the constant in the source file is utf8
- If I save the source (in utf8), without a utf8 BOM, then it works
fine on windows.
- If I had a bom, then the string received by the function appears to
be ascii (checked memory dump in debugger oe becomes d6
- if I add {$codepage utf8} it also becomes ascii
If I do *not* add that, it seems something gos wrong with the encoding
on a PowerPC Mac. Unfortunately this is someone else's pc, and I have
no more info.
If I add it things also go wrong, only different. Again no more info.
---
I know the provided info, is very little. If there is anything obvious
then tell me.
Thanks
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Probably this is due to significant change in FPC 2.7 RTL
*String* type implies the encoding inside
under WIndows it is ANSI by default.
Try to write simple application that concatenates (s:=a+b) two strings
with umlauted letters.
The resulting string loose the umlauts under Windows.
The only thing that help at the RTL level -
{$ifdef FPC}
SetMultiByteConversionCodePage(CP_UTF8);
{$endif}
This brings similar behaviour for RTL functions ether in Windows and
UNIX but completely breaks file IO.
You wont be able to open file which names translates to
more-than-one-byte per symbol.
because RTL IO is ANSI-specific under Windows.
Other approach - use the *UnicodeString*. Forget the *string* type.
regards,
Anton
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
Am 18.12.2012 14:47, schrieb Anton Kavalenka:
On 15.12.2012 21:35, Martin wrote:
I am trying to figure out how to do that, or what I do wrong. I found
a page about $codepage, but it did not help
http://wiki.freepascal.org/LCL_Unicode_Support
I didnt find the fpc specific page, if exists (I suspect it does)
I am calling a function function Foo(A:string) {$mode objfpc}{$H+}
I call it with a constant, that contains an german umlaut. Checked
with a hex editor, the constant in the source file is utf8
- If I save the source (in utf8), without a utf8 BOM, then it works
fine on windows.
- If I had a bom, then the string received by the function appears to
be ascii (checked memory dump in debugger oe becomes d6
- if I add {$codepage utf8} it also becomes ascii
If I do *not* add that, it seems something gos wrong with the
encoding on a PowerPC Mac. Unfortunately this is someone else's pc,
and I have no more info.
If I add it things also go wrong, only different. Again no more info.
---
I know the provided info, is very little. If there is anything
obvious then tell me.
Thanks
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Probably this is due to significant change in FPC 2.7 RTL
*String* type implies the encoding inside
under WIndows it is ANSI by default.
Martin's question is related to 2.6.0 (see his mail's subject) not 2.7.1.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
As Sven wrote, I guess the FPC community needs to think about this. XE2 already supported MacOS X (but through fpc). Haven't checked the OS-X in XE3 though. As for the multi-platform: they are rewriting their compiler to be a front for llvm. Probably they will make a few code-generators and optimisations as well for the middle and back-end. But I doubt the bpl idiom was or will get ported past Windows variants (if it even gets done in the new compiler format). Don't forget that with FireMonkey^2, and a Firemonkey component model, they plan to tackle facade-type implementations to make Android/IOS an output target as well from the same code-base. As is today with the MacOSX target in XE2 and XE3, there are restrictions as to what you can use (i.e. must be firemonkey HD or 3D app if you want Mac or x-platform, meaning 2 platforms ... well, 3 if you count Win32 and Win64 as separate :-)) That said, what is stopping us (the community) to at least start on this? a branch? core-buy-in? kind regards, Dimitri Smits - Oorspronkelijk e-mail - Van: Hans-Peter Diettrich drdiettri...@aol.com Aan: FPC developers' list fpc-devel@lists.freepascal.org Verzonden: Maandag 17 december 2012 16:20:39 Onderwerp: 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 ___ 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 18.12.2012 15:00, schrieb Dimitri Smits: As Sven wrote, I guess the FPC community needs to think about this. XE2 already supported MacOS X (but through fpc). Haven't checked the OS-X in XE3 though. Only iOS was done through FPC. Mac OS X itself was already done through Embarcadero's compiler in XE 2. As for the multi-platform: they are rewriting their compiler to be a front for llvm. Probably they will make a few code-generators and optimisations as well for the middle and back-end. But I doubt the bpl idiom was or will get ported past Windows variants (if it even gets done in the new compiler format). Don't forget that with FireMonkey^2, and a Firemonkey component model, they plan to tackle facade-type implementations to make Android/IOS an output target as well from the same code-base. As is today with the MacOSX target in XE2 and XE3, there are restrictions as to what you can use (i.e. must be firemonkey HD or 3D app if you want Mac or x-platform, meaning 2 platforms ... well, 3 if you count Win32 and Win64 as separate :-)) They don't need to implement it for each target like we won't implement it for each target either (thinking about DOS, NDS, GBA, Wii and embedded here). That said, what is stopping us (the community) to at least start on this? a branch? core-buy-in? From my side: time :) (and a huge list of other features I want to have implemented first) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building the Android branch
Am 18.12.2012 14:22, schrieb Sven Barth: Am 18.12.2012 14:15, schrieb Thomas Schatzl: I now simply replaced my 2.6.0 fpcmake with one compiled from the Android branch and were happy to go :) So I (this time on Windows) managed to compile and install the branch and now just need to check whether it will work... Now I just need to test whether the Android LCL test application/library works... Thank you so far :D I never tried the LCL, but with some hacking of android makefiles I managed to create and run some opengl demo application. Use the NDK bindings on lazarus-ccr; just looked, the bindings are still there, but that example application seems to be gone. I heard other people were successful with a hacked arm/linux compiler before that branch started. Of course, console apps like the compiler to do e.g. a make cycle also worked last time I tried. I successfully compiled the lcl-customdrawn example library, but the Java side code does not like the idea of being compiled -.- I'll need to look into this... Ok, the problem with the Java side code was that I didn't have the corresponding Java API installed (version 8)... Now I can build the package, but I get a link error from Android. Looking at the output of objdump I can't mind that it has problems: === objdump begin === D:\lazarus\1.0\examples\androidlcl\android\libs\armeabi\liblclapp.so: file format elf32-littlearm Program Header: LOAD off0x vaddr 0x paddr 0x align 2**15 filesz 0x00425dc0 memsz 0x00425dc0 flags r-x LOAD off0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**15 filesz 0x0001f9c8 memsz 0x00033a28 flags rw- DYNAMIC off0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**2 filesz 0x00c8 memsz 0x00c8 flags rw- STACK off0x vaddr 0x paddr 0x align 2**2 filesz 0x memsz 0x flags rwx Dynamic Section: NEEDED D:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\\libdl.so NEEDED libjnigraphics.so NEEDED liblog.so SONAME liblclapp.so INIT 0x000beea4 FINI 0x000e069c HASH 0x00b4 STRTAB 0x021c SYMTAB 0x010c STRSZ0x02a8 SYMENT 0x0010 PLTGOT 0x004280c8 PLTRELSZ 0x0018 PLTREL 0x0011 JMPREL 0x000bee54 REL 0x04c4 RELSZ0x000be990 RELENT 0x0008 TEXTREL 0x RELCOUNT 0x00017d32 private flags = 502: [Version5 EABI] [has entry point] === objdump end === The first one shouldn't be the full pathname... also isn't the linker on Android called /system/bin/linker? Do I need any further options besides the -Xp..., -FD..., -Fl..., -CpARMv6 and -CfSoft to build a library? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building the Android branch
Am 18.12.2012 17:24, schrieb Sven Barth: Am 18.12.2012 14:22, schrieb Sven Barth: Am 18.12.2012 14:15, schrieb Thomas Schatzl: I now simply replaced my 2.6.0 fpcmake with one compiled from the Android branch and were happy to go :) So I (this time on Windows) managed to compile and install the branch and now just need to check whether it will work... Now I just need to test whether the Android LCL test application/library works... Thank you so far :D I never tried the LCL, but with some hacking of android makefiles I managed to create and run some opengl demo application. Use the NDK bindings on lazarus-ccr; just looked, the bindings are still there, but that example application seems to be gone. I heard other people were successful with a hacked arm/linux compiler before that branch started. Of course, console apps like the compiler to do e.g. a make cycle also worked last time I tried. I successfully compiled the lcl-customdrawn example library, but the Java side code does not like the idea of being compiled -.- I'll need to look into this... Ok, the problem with the Java side code was that I didn't have the corresponding Java API installed (version 8)... Now I can build the package, but I get a link error from Android. Looking at the output of objdump I can't mind that it has problems: === objdump begin === D:\lazarus\1.0\examples\androidlcl\android\libs\armeabi\liblclapp.so: file format elf32-littlearm Program Header: LOAD off0x vaddr 0x paddr 0x align 2**15 filesz 0x00425dc0 memsz 0x00425dc0 flags r-x LOAD off0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**15 filesz 0x0001f9c8 memsz 0x00033a28 flags rw- DYNAMIC off0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**2 filesz 0x00c8 memsz 0x00c8 flags rw- STACK off0x vaddr 0x paddr 0x align 2**2 filesz 0x memsz 0x flags rwx Dynamic Section: NEEDED D:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\\libdl.so NEEDED libjnigraphics.so NEEDED liblog.so SONAME liblclapp.so INIT 0x000beea4 FINI 0x000e069c HASH 0x00b4 STRTAB 0x021c SYMTAB 0x010c STRSZ0x02a8 SYMENT 0x0010 PLTGOT 0x004280c8 PLTRELSZ 0x0018 PLTREL 0x0011 JMPREL 0x000bee54 REL 0x04c4 RELSZ0x000be990 RELENT 0x0008 TEXTREL 0x RELCOUNT 0x00017d32 private flags = 502: [Version5 EABI] [has entry point] === objdump end === The first one shouldn't be the full pathname... also isn't the linker on Android called /system/bin/linker? Do I need any further options besides the -Xp..., -FD..., -Fl..., -CpARMv6 and -CfSoft to build a library? Ok... first: it was a stray -FLlibdl.so from a former test with non working binutils. When I remove it the library can't be linked though... The following options are set in fpc.cfg for Android: -XParm-linux-androideabi- -FDD:\Android\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin -FlD:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\ The following arguments are added by Lazarus (the last three were already part of the project - removing -Xd does also not change anything): -MObjFPC -Scghi -O1 -Tandroid -Parm -Xs -XX -vewnhi -l -Filib\arm-android -Fu..\..\lcl\units\arm-android\customdrawn -Fu..\..\lcl\units\arm-android -Fu..\..\components\lazutils\lib\arm-android -Fu..\..\packager\units\arm-android -Fu. -FUlib\arm-android\ -FEandroid\libs\armeabi\ -oliblclapp.so -dLCL -dLCLcustomdrawn -dANDROID -Xd -CpARMV6 Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building the Android branch
Hi, On Tue, 2012-12-18 at 17:35 +0100, Sven Barth wrote: === objdump end === The first one shouldn't be the full pathname... also isn't the linker on Android called /system/bin/linker? You're trying to generate an executable or a shared library (.so)? Do I need any further options besides the -Xp..., -FD..., -Fl..., -CpARMv6 and -CfSoft to build a library? Ok... first: it was a stray -FLlibdl.so from a former test with non working binutils. You mean the one with the full path has been added in error? When I remove it the library can't be linked though... What is it exactly? Which library cannot be linked? What's the error? Just checked, for libraries /system/bin/linker should be added automatically (compiler/systems/t_android.pas) The following options are set in fpc.cfg for Android: -XParm-linux-androideabi- -FDD:\Android\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin -FlD:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\ The following arguments are added by Lazarus (the last three were already part of the project - removing -Xd does also not change anything): -MObjFPC -Scghi -O1 -Tandroid -Parm -Xs -XX -vewnhi -l -Filib\arm-android -Fu..\..\lcl\units\arm-android\customdrawn -Fu..\..\lcl\units\arm-android -Fu..\..\components\lazutils\lib\arm-android -Fu..\..\packager\units\arm-android -Fu. -FUlib\arm-android\ -FEandroid\libs\armeabi\ -oliblclapp.so -dLCL -dLCLcustomdrawn -dANDROID -Xd -CpARMV6 Looks okay, but I will see if I can find these tests I was mentioning. That stuff is on a different computer though. Looking through compiler/systems/t_android.pas, you may want to try commmenting line 343, the one that adds info.Dynamiclinker to the input files. Looks wrong. (system/bin/linker is passed to ld later as --dynamic-linker option later anyway). Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building the Android branch
Am 18.12.2012 17:47 schrieb Thomas Schatzl tom_at_w...@gmx.at: Hi, On Tue, 2012-12-18 at 17:35 +0100, Sven Barth wrote: === objdump end === The first one shouldn't be the full pathname... also isn't the linker on Android called /system/bin/linker? You're trying to generate an executable or a shared library (.so)? A shared library as this is what's needed for usage of the LCL. See also examples/androidlcl of a current Lazarus version (at least 1.0). Do I need any further options besides the -Xp..., -FD..., -Fl..., -CpARMv6 and -CfSoft to build a library? Ok... first: it was a stray -FLlibdl.so from a former test with non working binutils. You mean the one with the full path has been added in error? Yes. The binutils with version 2.19 crashed without reasons and on the Lazarus forum there were suggestions to add -FLlibdl.so. I had added that to the fpc.cfg and forgot to remove it when I cleanly rebuild with the 2.21 binutils. This was all before I started to write you. When I remove it the library can't be linked though... What is it exactly? Which library cannot be linked? What's the error? it was the -FLlibdl.so and the library is the one I'm trying to build. Sorry for the confusion. Just checked, for libraries /system/bin/linker should be added automatically (compiler/systems/t_android.pas) The following options are set in fpc.cfg for Android: -XParm-linux-androideabi- -FDD:\Android\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin -FlD:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\ The following arguments are added by Lazarus (the last three were already part of the project - removing -Xd does also not change anything): -MObjFPC -Scghi -O1 -Tandroid -Parm -Xs -XX -vewnhi -l -Filib\arm-android -Fu..\..\lcl\units\arm-android\customdrawn -Fu..\..\lcl\units\arm-android -Fu..\..\components\lazutils\lib\arm-android -Fu..\..\packager\units\arm-android -Fu. -FUlib\arm-android\ -FEandroid\libs\armeabi\ -oliblclapp.so -dLCL -dLCLcustomdrawn -dANDROID -Xd -CpARMV6 Looks okay, but I will see if I can find these tests I was mentioning. That stuff is on a different computer though. Looking through compiler/systems/t_android.pas, you may want to try commmenting line 343, the one that adds info.Dynamiclinker to the input files. Looks wrong. (system/bin/linker is passed to ld later as --dynamic-linker option later anyway). I will try that. Regards, Sven ___ 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: Hi, Any FPC developer willing to comment on the status of some of these issues (that have been years overdue)? It narrows basically down to the fact that fpc lacks developers and contributors, or do I miss something? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
2012/12/18 Florian Klämpfl flor...@freepascal.org: Am 17.12.2012 10:36, schrieb Graeme Geldenhuys: Hi, Any FPC developer willing to comment on the status of some of these issues (that have been years overdue)? It narrows basically down to the fact that fpc lacks developers and contributors, or do I miss something? That, combined with the fact that the existing developers and contributors spend their resources on different things than the original poster seems desirable. Vincent ___ 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 18.12.2012 19:17, schrieb Vincent Snijders: 2012/12/18 Florian Klämpfl flor...@freepascal.org: Am 17.12.2012 10:36, schrieb Graeme Geldenhuys: Hi, Any FPC developer willing to comment on the status of some of these issues (that have been years overdue)? It narrows basically down to the fact that fpc lacks developers and contributors, or do I miss something? That, combined with the fact that the existing developers and contributors spend their resources on different things than the original poster seems desirable. Well, the more contributors, the more likely it is that several features are implemented, so this is imo already a consequence. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
