[fpc-devel] rev 19036 breaks the Android cross-compiler

[Thomas Schatzl]

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 completely breaks linking
> Android projects.

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