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 _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
