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.php/topic,15108.15.html

Hi,

Arm-Android has never been and is still not supported by any FPC version. scnr.

The behavior introduced in the change is correct for the reasons stated in the extensive revision log comment. In short, otherwise shared library initialization and finalization of fpc-only shared libraries do not work on Debian-Linux systems of any hardware platform.

(One of the original issues which caused the investigation into that is that Debian seems to compile the dynamic loader with assertions enabled, and not linking to the loader stub (ld.so.3 etc) makes that assertion fail on any pure FPC shared library in the linker at program exit (or startup?). It's just wrong to not link to some sort of dynamic loader stub for dynamic libraries - other Linux distro's just ignore that error and do "something" instead.)

You could try to somehow fake linking to libc for your shared library. In that case that dependency is not emitted (That works because it is known that libc has a dependency to ld.so.3 or whatever linker is used on the platform). But then, probably, your shared library may crash too because the linux-arm startup code when linking to libc has been coded for GNU libc.

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 verified that in the bionic sources; other *nixes, eg. BSDs, are the same. Passing the environment to shared libraries is particular to Linux and only supported there. They must be retrieved later by other means (in some special android RTL). So at the moment your Android shared library will probably crash as soon as it tries to access information from these variables.

And that's just the known issues with using the arm-linux compiler for arm-android. Previously it just worked by coincidence, by omitting otherwise required work.

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 which would be another way of hacking in "support") is to add an explicit arm-android target that reuses most of *nix/linux rtl in some way.

Patches that add a new target are welcome (or other contributions to that effect that are not hacks). Unfortunately I cannot really help with coding, but I can help with explaining what/where to change, due to lack of hardware.

Note that afaik, r19036 will be in 2.6 (it has been overlooked for rc1 iirc, if you tried) as it fixes several issues on five supported targets and (unfortunately) breaks one never supported one. I hope this is understandable.

Hth,
Thomas

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 just copying everything and making the Android fixes.

Unfortunately I cannot really help with coding, but I can help with explaining what/where to change, due to lack of hardware.

If that is the only problem you should know that the Android SDK comes with an emulator and there are instructions about how to install and use it here:

http://wiki.lazarus.freepascal.org/Android_Interface/Using_the_Android_SDK%2C_Emulator_and_Phones#Using_the_Emulator

That is probably the worst you can do.

Long-term, this will lead to serious maintenance overhead.

So it's probably a lot easier to just IFDEF with a -DANDROID or so, and recompile the linux target specifically for android.

Michael.

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 about this error before, is it also a breakage introduced in 2.7?

Because I tested sysutils in my 2.5 cross-compiler and it works fine.

Hi,

It's not that much of work as it sounds, but still somebody needs to commit to it, preferably not only as a one-shot effort. The changes should be regularly verified and tested too (say: at release time).

What you propose may be a short-term solution to the problem. If others are okay with that, I won't object to put any "short-term" hacks (that usually persist until the end of time) into the svn under a define.

I do know that, I tried it once or twice. It takes ages to start up and it's sluggish beyond usefulness on my venerable single-core 1.5Ghz P-M... which is the fastest x86 computer I own.

Apart from that, time is also an issue, sorry. It took at least a few months until I managed to complete r19036 - not because it's that much code but looking for documentation, finding out the issue, digging through libc source code and then verifying and testing for multiple platforms just takes time (and repeat everything after any last-minute change). I'm simply usually either busy or too tired to start hacking at 10/11pm just for one or two hours.
I will try and see what I can do, but e.g. that associated bugtracker issue (18833) about the broken shared library startup code for android has already been in the bugtracker for 9 months...

Hth,
Thomas

Hi,

It's not a "breakage" introduced in 2.7. Please accept that the problem exists since forever and it just coincidently works. There is a bug report (18833) which exactly reports that for 2.5.1 too.

Maybe you're using an already partially patched crosscompiler. It should be 100% reproducible on *any* fpc version when using the arm-linux compiler for arm-android.
If it works, you are consistently really lucky.

Thomas

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/

And ever since it worked excelently.

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 running on Android.

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 running on Android.

Looks like I was correct:

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=16981

Nearly at 100% this change caused the break.

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 breaking change though, only another incompatibility of Android with regular Linux (which is their full right, since they don't advertise Linux-compatibility afaik).

Jonas

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 IFDEF ANDROID, but I do hope that if we introduce it I won't hear in the future when a commit breaks it that it is unsupported so we shouldn't care about that.

I was opposed to adding {$ifdef android} stuff to the Linux rtl and then letting people compile the Linux rtl with this define for Android (there are already enough different ARM-Linux variants that cause confusion). 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).

Jonas

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 breaking change though, only another incompatibility of Android with regular Linux (which is their full right, since they don't advertise Linux-compatibility afaik).

argc/argv are useless in Android JNI libraries, I can't imagine any use for that. I think that having them as zero is just fine for the future android target.

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 expected at all to work in Android, and if they work it is pure luck, but still the android target should use them? Just to add the work of having to figure out what was broken when people change the linux rtl files without care for the android target?

In my opinion, the point is:

1) Different (compiled) versions of the RTL are required for real Linux and Android anyway, so it makes sense to declare them as two distinct targets (similarly to e.g. Darwin and FreeBSD).

2) As you correctly mention, the difference in behaviour requires someone to take care about possible incompatibilities actively. The behaviour of the platform differs and you cannot expect that current maintainers of the Linux port take responsibility for testing Android compatibility in addition to the Linux compatibility. Obviously, people making changes should be aware that some parts are shared (similarly to Jonas and Marco discussing impacts of some BSD related changes), but that doesn't mean that everything always works out of the box.

Tomas

Hi,

If you have a look at the arm-linxu/dllprt0.as as of 19th of January (http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/linux/arm/dllprt0.as?revision=15484&view=markup) you will see that it does not initialize argc, argv and envp variables. Actually it does nothing. Even without assembler knowledge you will see that these variables are never even referenced in that code, while it is the responsibility of that code, just have a look at other startup code. You will get whatever has been in them before initialization, most likely NULL values if you are loading the , that startup code does not call shared library initialization either (initialization sections), and does not register a finalization function, i.e. finalization of shared libraries does not work. Only r19036 implemented that for all Linux platforms.

Looking more closely at android, there might be even more incompatibilities and differences to arm-linux than discussed so far. E.g. I also think (not sure) that its libc is the official interface to the OS functions too, so you probably should not use syscalls there but by default interface to libc (similar to OS X).
Android does not advertise Linux compatibility after all.

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.

Thomas

Ok, now I see that there is good will, and that's the most important part =)

I will see what I can do on my part to help here. (continuing in private)

There is the ability to use a different startup code. It just works a bit complicated, because it works on the type of the detected c-library. Especially when cross compiling one needs to be careful. E.g. I myself have a glibc i386 system, but cross compile for a uclibc ARM one. The responsible code is in $fpcdir/compiler/systems/t_linux.pas and there TLinkerLinux.InitSysInitUnitName. So in theory it should be possible to extend this by a detection for the Android bionic library (as the library needs to be available when cross compiling this should at least in theory be possible).

Regards,
Sven

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 "sub architectures" out there having an own target for each of them isn't a good idea either. Maybe we can even introduce some SUBARCH in the long term into our build system.

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 dynamic linker).

Jonas

But gcc considers it as arm-linux-eabi as well, no?

Hi,

No, it's a target called arm-android-eabi.

$ ./arm-linux-androideabi-gcc -v
Using built-in specs.
Target: arm-linux-androideabi
Configured with: /tmp/ndk-digit/src/build/../gcc/gcc-4.4.3/configure --prefix=/usr/local/google/digit/repo/opensource/ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86 --target=arm-linux-androideabi --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-gnu-as --with-gnu-ld --enable-languages=c,c++
--with-gmp=/tmp/ndk-digit/build/toolchain/temp-install --with-mpfr=/tmp/ndk-digit/build/toolchain/temp-install --disable-libssp --enable-threads --disable-nls --disable-libmudflap --disable-libgomp --disable-libstdc__-v3 --disable-sjlj-exceptions --disable-shared --disable-tls --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace --enable-initfini-array --disable-nls --prefix=/usr/local/google/digit/repo/opensource/ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86 --with-sysroot=/usr/local/google/digit/repo/opensource/ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/sysroot --with-binutils-version=2.20.1 --with-mpfr-version=2.4.1 --with-gmp-version=4.2.4 --with-gcc-version=4.4.3 --with-gdb-version=6.6 --with-arch=armv5te
--program-transform-name='s,^,arm-linux-androideabi-,' Thread model: posix
gcc version 4.4.3 (GCC)

Thomas

Hmm? I read "arm-linux" there with an ABI that's specific to Android...

Regards,
Sven

But FPC also supports different C libraries (at least glibc and uclibc). And they may have drastic differences, too, they simply didn't occur yet as not that many people are testing/using the uclibc support. So what would speak against adding another one and using (and if necessary adjusting) the libc variation of the RTL (if it's indeed not a good idea to use direct syscalls)?

Regards,
Sven

Hi,

My fault. I first googled for "arm-android-eabi", and there I got a gcc patch from 2008 where it is still called that way
(http://old.nabble.com/-PATCH--ARM--Support-arm-android-eabi-td18160980.html).

I then thought of downloading the ndk and issuing that command, did that, copy&pasted it into the email and immediately sent it without looking :)

(that post:
http://old.nabble.com/-PATCH--ARM--Support-arm-android-eabi-td18160980.html)

At some point that changed for whatever reason.

Note that I do not think that this changes much, even worse, it means we actually need a compiler target anyway because of different ABI to normal linux. Additionally, as I already said once, bionic is very likely the official OS interface, so we should use that like in OS X (and syscalls are subject to change; need to check that).

Thomas

In our previous episode, Felipe Monteiro de Carvalho said:

As Jonas already explained, the unix rtl works that way. E.g. FreeBSD, OpenBSD and Mac share parts with all unix targets (unix/ dir), and parts with other BSDs and Mac OS X (BSD).

But they all have their own directory (freebsd/ darwin/ openbsd/) and makefile and compiler targets.

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 library and the dynamic linker). 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.

Would anyone possibly consider creating releases for Android in the future (even if just for cross-compilation purposes)? If this is the case, I'd say that having a distinct target might make sense...

Tomas

I don't know whether it's formally, but the compiler contains enough code to automatically detect the c libary (from the set of supported c libraries) you are using. It doesn't even matter whether you're cross compiling or not (though the first requires some further options so that the compiler detects the library of the target system and not your own). I personally use that feature for a small uclibc based Linux system of mine and so far(!) it works.

Regards,
Sven

In our previous episode, Sven Barth said:

"Tries to do a first order guess" is a better description than automated IMHO :_0

But yes. I forgot that since FPC is mostly static, it doesn't matter much what the release is linked against. (well, except for the IDE obviously)

It's not just cross compiling. bi/multi-arch distributions are also pain.

There are some very old bugreports about this, and at the time Florian talked about introducing sub-architectures, but the details never fleshed out.

Anyway, I think it would be good to simply being able to disable the detection and override selection. (and that should IMHO be a rule for every automatism: provide a way to disable/overrule it, IOW invoking human's privilege over machines). It then can be simply added to CROSSOPT during build.

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 dynamic linker).

Do you suggest that the normal Linux Kernel API is not available for a native code application running in an Android device ?

Do you suggest that a native code application running in an Android device can't use the normal gnu libc API ?

Do you suggest (many of the) normal gnu (command-line) tools (that usually run on i/o pipes) can't be installed on an Android device ?

Of course some care needs to be taken when trying to use any "normal" devices, as those might be non-existing or working differently in an Android device.

Of course when doing a much GUI care needs to be taken, as in an Android device you supposedly can't just use the X server API to create a window on the screen.

-Michael

Florian Klämpfl wrote

But gcc considers it as arm-linux-eabi as well, no?

There also is Android fox x86 (and whatever..)

-Michael

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.

Do you suggest that a native code application running in an Android device can't use the normal gnu libc API ?

Android has a libc (called 'bionic'), but it might not be entirely compatible to the GNU one, thus unexpected errors in the libc variant of FPC's RTL could happen and this should be taken care of.

And these two points explain why its not trivial or risk free to use stock FPC for Android.

Do you suggest (many of the) normal gnu (command-line) tools (that usually run on i/o pipes) can't be installed on an Android device ?

Such command line tools might be used, but they need to be recompiled. For C based application this is simple, because they just need to use the correct headers, but for FPC there might be the posibility that one must port some functions.

Regards,
Sven

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 think about this statement:

http://groups.google.com/group/android-ndk/browse_thread/thread/3247d4a02d3e530c

Their answer:

<quote>
The Android team has not intention to delete or modify syscalls, that would be crazy.

On the other hand, there is no guarantee on the exact set of syscalls or config options supported by a given device kernel.

When it comes to simple runtime syscalls, these shouldn't be a problem, and would advise you to keep doing what you're doing. </quote>

So from their answer I understand that we can keep using the syscalls which are currently using, although of course the answer was not cristal clear. Changing to libc could also bring issues and if it is not broken I would not change what is done now.