On Wed, Nov 16, 2011 at 5:05 PM, Sven Barth wrote:
> Google does not state that its OS is Linux compatible, thus in theory they
> can add, modify or delete syscalls of the OS. While an addition is no
> problem for FPC and its RTL, a modification or deletion is.
I decided to ask Google what they t
Am 16.11.2011 11:45, schrieb Michael Schnell:
On 11/15/2011 09:12 PM, Jonas Maebe wrote:
Android isn't a different architecture (if you consider native
applications), but a different OS. It uses a Linux kernel (although
even that one is heavily patched, afaik), and user land is obviously
quite d
On 11/15/2011 09:13 PM, Florian Klämpfl wrote:
But gcc considers it as arm-linux-eabi as well, no?
There also is Android fox x86 (and whatever..)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/
On 11/15/2011 09:12 PM, Jonas Maebe wrote:
Android isn't a different architecture (if you consider native applications),
but a different OS. It uses a Linux kernel (although even that one is heavily
patched, afaik), and user land is obviously quite different (including the C
library and the dy
In our previous episode, Sven Barth said:
> >> But FPC also supports different C libraries (at least glibc and uclibc).
> >
> > Do we? Formally I mean? A few patches that allow interested people to play
> > with it, is something else from a supported target.
>
> I don't know whether it's formall
Am 16.11.2011 10:33, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
Android isn't a different architecture (if you consider native applications),
but a different OS. It uses a Linux kernel (although even that one is heavily
patched, afaik), and user land is obviously qui
On Tue, November 15, 2011 21:13, Florian Klämpfl wrote:
> Am 15.11.2011 21:12, schrieb Jonas Maebe:
>> On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
>>
>>> I dn't know if this is a good long term solution: I fear too much
>>> duplication with having a seperate android target. I'd prefer an
>>> F
In our previous episode, Sven Barth said:
> > Android isn't a different architecture (if you consider native
> > applications), but a different OS. It uses a Linux kernel (although even
> > that one is heavily patched, afaik), and user land is obviously quite
> > different (including the C libra
In our previous episode, Felipe Monteiro de Carvalho said:
> > Having a separate Android target that reuses files from the Linux directory
> > and adding defines for that is fine (all Unix rtls share files that way).
>
> This does not make the slightest sense. So the files in the linux
> director
Hi,
Am 15.11.2011 21:39, schrieb Sven Barth:
On 15.11.2011 21:33, Thomas Schatzl wrote:
But gcc considers it as arm-linux-eabi as well, no?
No, it's a target called arm-android-eabi.
$ ./arm-linux-androideabi-gcc -v
Using built-in specs.
Target: arm-linux-androideabi
Hmm? I read "arm-linux
On 15.11.2011 21:12, Jonas Maebe wrote:
On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
I dn't know if this is a good long term solution: I fear too much
duplication with having a seperate android target. I'd prefer an
FPC_ANDROID define, I don't think that it will pollute the rtl and
conside
On 15.11.2011 21:33, Thomas Schatzl wrote:
But gcc considers it as arm-linux-eabi as well, no?
No, it's a target called arm-android-eabi.
$ ./arm-linux-androideabi-gcc -v
Using built-in specs.
Target: arm-linux-androideabi
Hmm? I read "arm-linux" there with an ABI that's specific to Android.
Hi,
Am 15.11.2011 21:13, schrieb Florian Klämpfl:
Am 15.11.2011 21:12, schrieb Jonas Maebe:
On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
I dn't know if this is a good long term solution: I fear too much
duplication with having a seperate android target. I'd prefer an
FPC_ANDROID define,
Am 15.11.2011 21:12, schrieb Jonas Maebe:
>
> On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
>
>> I dn't know if this is a good long term solution: I fear too much
>> duplication with having a seperate android target. I'd prefer an
>> FPC_ANDROID define, I don't think that it will pollute the
On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
> I dn't know if this is a good long term solution: I fear too much
> duplication with having a seperate android target. I'd prefer an
> FPC_ANDROID define, I don't think that it will pollute the rtl and
> considering that there are a lot of arm "s
Am 15.11.2011 16:02, schrieb Jonas Maebe:
>
> On 15 Nov 2011, at 15:57, Felipe Monteiro de Carvalho wrote:
>
>> On Tue, Nov 15, 2011 at 2:51 PM,
>> wrote:
>>> So it's probably a lot easier to just IFDEF with a -DANDROID or
>>> so, and recompile the linux target specifically for android.
>>
>>
On 15.11.2011 14:18, Thomas Schatzl wrote:
Arm-linux and arm-android are really different in regards to startup,
and likely not only that. The easiest (and most clean) way to do this in
a compiler supported way (there is no "OS-variant" notion in the
compiler to pass custom startup files iirc whi
On Tue, Nov 15, 2011 at 4:59 PM, Thomas Schatzl wrote:
> That's why I suggested and support effort on implementing that using a
> different target.
>
> As already mentioned, I will spend time on it, but do not expect
> anything quickly for reasons already explained.
Ok, now I see that there is go
Hi,
On Tue, 2011-11-15 at 15:42 +0100, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 3:35 PM, Thomas Schatzl wrote:
> > Maybe you're using an already partially patched crosscompiler.
>
> No, I am not. I built it myself in 19/Jan without any patches against
> fpc trunk and uploaded
On Tue, November 15, 2011 16:27, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 4:02 PM, Jonas Maebe
> wrote:
>> Having a separate Android target that reuses files from the Linux
>> directory and adding defines for that is fine (all Unix rtls share files
>> that way).
>
> This does n
On Tue, Nov 15, 2011 at 4:02 PM, Jonas Maebe wrote:
> Having a separate Android target that reuses files from the Linux directory
> and adding defines for that is fine (all Unix rtls share files that way).
This does not make the slightest sense. So the files in the linux
directory are not expect
On Tue, Nov 15, 2011 at 3:55 PM, Jonas Maebe wrote:
> Before that change, argc/argv were simply not initialized in ARM shared
> libraries and hence were always 0. Maybe the difference is that earlier, you
> always got paramcount=0
> and now you get a crash on Android. I would not call that a bre
On 15 Nov 2011, at 15:57, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 2:51 PM, wrote:
>> So it's probably a lot easier to just IFDEF with a -DANDROID or so,
>> and recompile the linux target specifically for android.
>
> I had already proposed this previously and Jonas rejecte
On Tue, Nov 15, 2011 at 2:51 PM, wrote:
> So it's probably a lot easier to just IFDEF with a -DANDROID or so,
> and recompile the linux target specifically for android.
I had already proposed this previously and Jonas rejected it, so I
proposed now something different.
But I am not against the
On 15 Nov 2011, at 15:49, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 3:42 PM, Felipe Monteiro de Carvalho
> wrote:
>> So if anything was broken before rev19036 it was after 19th January or
>> it requires something special to reproduce. So far I haven't found any
>> issues with
On Tue, Nov 15, 2011 at 3:42 PM, Felipe Monteiro de Carvalho
wrote:
> So if anything was broken before rev19036 it was after 19th January or
> it requires something special to reproduce. So far I haven't found any
> issues with libraries or even executables built with that
> cross-compiler while r
On Tue, Nov 15, 2011 at 3:35 PM, Thomas Schatzl wrote:
> Maybe you're using an already partially patched crosscompiler.
No, I am not. I built it myself in 19/Jan without any patches against
fpc trunk and uploaded it here:
http://sourceforge.net/projects/p-tools/files/Free%20Pascal%20for%20ARM/
Hi,
On Tue, 2011-11-15 at 14:51 +0100, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 2:18 PM, Thomas Schatzl wrote:
> > But that's not the only thing about shared library startup that is
> > different of vanilla Linux to Android. E.g. second known issue is that
> > shared libraries
Hi,
On Tue, 2011-11-15 at 14:34 +0100, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 2:18 PM, Thomas Schatzl wrote:
> > Patches that add a new target are welcome (or other contributions to
> > that effect that are not hacks).
>
> If noone can do anything about this then I propose
On Tue, Nov 15, 2011 at 2:18 PM, Thomas Schatzl wrote:
> But that's not the only thing about shared library startup that is
> different of vanilla Linux to Android. E.g. second known issue is that
> shared libraries do not get argc/argv/envp passed correctly to the
> startup code.
I already heard
On Tue, 15 Nov 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Nov 15, 2011 at 2:18 PM, Thomas Schatzl wrote:
Patches that add a new target are welcome (or other contributions to
that effect that are not hacks).
If noone can do anything about this then I propose to fork a new
android targ
On Tue, Nov 15, 2011 at 2:18 PM, Thomas Schatzl wrote:
> Patches that add a new target are welcome (or other contributions to
> that effect that are not hacks).
If noone can do anything about this then I propose to fork a new
android target out of linux without using code from linux but instead
j
Hi,
On Tue, 2011-11-15 at 10:30 +0100, Felipe Monteiro de Carvalho wrote:
> Hello,
>
> http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=19036
>
> by tom_at_work
>
> Adds a dependency on all Linux shared objects to /lib/ld-linux.so.3
> which does not exist in Android, so it complet
Hello,
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=19036
by tom_at_work
Adds a dependency on all Linux shared objects to /lib/ld-linux.so.3
which does not exist in Android, so it completely breaks linking
Android projects.
=(
See also: http://www.lazarus.freepascal.org/index
34 matches
Mail list logo
