Hello,

Quite a number of people already reported having problems with this in the lazarus forum when cross-compiling for Android and yesterday it was my turn to hit this. I searched quite a bit in old threads but I haven't seen any satisfactory resolution, and it seams that the problem isnt so common outside fpc.

Basically I have 2 computers, which AFAIK have nearly the same set of tools: 1> FPC 2.6 RC1
2> My snapshot FPC 2.5.1 cross-compiler x86-linux -> arm-linux 3> Lazarus from SVN
4> Mageia Linux 1
5> Building the project lazarus-ccr/examples/androidlclv2 6> Android NDK r5

I think they have cross-binutils from the same rpm too, but I still have to recheck this.

The first computer is a real desktop and there everything works fine. I can built the application normally linking against the NDK

The second one is a virtual machine running in Parallels Desktop, but Parallels is nearly perfect ... I am yet to find a bug which is caused due to the virtual machine. And a lot of people have been reporting this in the forum, so it seams a common problem which affects real computers too.

In my case even the directory structure in both machines is the same, so I pass my library -Fl path in both like this:

/home/felipe/Programas/android-ndk-r5/platforms/android-9/arch-arm/usr/lib/

There are no changes here in anything of my source project and lazarus source, I checked with "svn diff", but in virtual machine I get the infamous errors from arm-linux-ld:

Compiling resource
/home/felipe/Programas/lazarus-ccr/examples/androidlclv2/lib/arm-linux/androidlcltest.or Linking /home/felipe/Programas/lazarus-ccr/examples/androidlclv2/android/libs/armeabi/libmain.so /usr/bin/arm-linux-ld: warning:
/home/felipe/Programas/lazarus-ccr/examples/androidlclv2/android/libs/armeabi/link.res contains output sections; did you forget -T?
/usr/bin/arm-linux-ld: skipping incompatible /usr/lib//libc.so when searching for -lc
/usr/bin/arm-linux-ld: skipping incompatible /usr/lib/crtn.o when searching for /usr/lib/crtn.o
/usr/bin/arm-linux-ld: cannot find /usr/lib/crtn.o androidlcltest.lpr(24) Error: Error while linking
androidlcltest.lpr(24) Fatal: There were 1 errors compiling module, stopping

arm-linux-ld seams to have a fixed idea about where to find libc and it refuses to search in my path from -Fl, but it finds libandroid.so correctly in the provided path, which is even more confusing.

I have trying all of the following things to try to fix it:

1> First I tryed to change that -Fl to
/home/felipe/Programas/android-ndk-r5/platforms/android-9/arch-arm/usr/ (with lib/)

Now it will complain that it can't find libandroid.so, so this shows that the previously utilized path is valid and recognized

2> I tryed to change /etc/ld.conf (or something like that). Didn't help, so I restored it back

3> I tryed:
export PATH=/home/felipe/Programas/android-ndk-r5/platforms/android-9/arch-arm/usr/lib:$PATH didn't help

4> I tryed to change the NDK between v5 and v7 to no help

5> I tryed both FPC 2.4.4 and FPC 2.6 as the x86-linux compiler in case the fpc binary was eating parameters or something like that (the arm-linux one never changes, and cannot be changed and is precisely the same in both cases, it was built in the real computer, but since the time it was built I have formatted my / partition and installed a newer version of my Linux)

6> I tryed:
export LIBPATH=/home/felipe/Programas/android-ndk-r5/platforms/android-9/arch-arm/usr/lib didn't help

7> Google didn't bring anything useful also, threads from C users seam to solve the issue with gcc options. example:
http://stackoverflow.com/questions/1964880/cannot-find-lib-libc-so-6

Points to using "-sysroot" from gcc

You could try to experiment with the "-L" argument of the linker (look at the man page of ld for info about it).

To experiment with the linker directly you can tell FPC to generate a link script using the option "-sh". Then you can modify the command line that is passed to the linker. After you've found what does you need to add you can pass the commands to FPC by using "-k", e.g. "-k-L/dir/to/your/libs" (no space between "-k" and the linker's options!).

I'm sorry that I can't help you more, but I'd first need to get my own ARM system running again (which I plan nevertheless, but not currently).

Regards,
Sven

Hello,

thanks for the tips, I figured out (although I still don't know if the resulting binary works).

> /usr/bin/arm-linux-ld: skipping incompatible /usr/lib//libc.so when > searching for -lc

This part was not a problem, it can be safely ignored.

If anyone wants to get rid of this message for no good reason, then
you can remove the -Fl and add this option to FPC:

-k--library-path=/home/felipe/Programas/android-ndk-r5/platforms/android-9/arch-arm/usr/lib/

> /usr/bin/arm-linux-ld: skipping incompatible /usr/lib/crtn.o when > searching for /usr/lib/crtn.o > /usr/bin/arm-linux-ld: cannot find /usr/lib/crtn.o > androidlcltest.lpr(24) Error: Error while linking

This was the real source of the problem. In the file link.res there is this code:

INPUT(
/usr/lib/crtn.o
)

It links if I change this to:

INPUT(
/home/felipe/Programas/android-ndk-r5/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/lib/gcc/arm-eabi/4.4.0/crtn.o )

So I can conclude 2 things:

1> We might have a problem because this crtn.o was removed from ndk-r7 as part of their removal for arm-eabi 4 support =( Maybe there is another file there in ndk-r7 which is equivalent with another name for eabi-5

2> It seams that FPC needs a command line option to specify where the extra input file is, if there isn't already one.
-k is not enough, because the link to /usr/lib/crtn.o is put into the link.res file, so we get no change to bypass that with -k

Felipe Monteiro de Carvalho wrote

arm-linux-ld seams to have a fixed idea about where to find libc

No, FPC has that fixed idea. Use the -Xd command line option to make the compiler/linker skip searching the default directories for libraries and object files. Alternatively, you can try the -XR/path/to/android_root command line option.

Jonas

Felipe Monteiro de Carvalho wrote

thanks for the tips, I figured out (although I still don't know if the resulting binary works).

Complementing: Yes, the binary works fine.

Felipe Monteiro de Carvalho wrote

1> We might have a problem because this crtn.o was removed from ndk-r7 as part of their removal for arm-eabi 4 support =( Maybe there is another file there in ndk-r7 which is equivalent with another name for eabi-5

There should be something similar as C applications AFAIK rely on this. Otherwise we'd need to change arm-linux to use an internal sysinit like i386-linux and the Windows targets do.

I have taken a look at the compiler's code that leads to the inclusion of "crtn.o" (for the curious:
compiler/systems/t_linux.pas/tlinkerlinux.WriteResponseFile). It searches for the file in the set library search path (this is extended by the "-Fl" option). Thus you should add - as Jonas wrote - the "-Xd" option which tells the compiler to not search in the default paths (the help of FPC even mentions that this option is "needed for cross compilation").

Regards,
Sven

Sven Barth wrote

There should be something similar as C applications AFAIK rely on this. Otherwise we'd need to change arm-linux to use an internal sysinit like i386-linux and the Windows targets do.

Yes, the ndk r7 has something similar, but it has many files, which look like this:

crtbegin.o
crtbeginS.o
crtbeginT.o
crtend.o
crtendS.o
libgcc.a
libgcov.a

In prebilt/linux-x86/lib/gcc/arm-linux-androideabi/4.4.3

There is no crtn.o in r7

In r5 there was:

crtbegin.o
crtend.o
crti.o
crtn.o
libgcc.a
libgcov.a

Quite interresting, Jonas did mention that, but I hadn't understood his e-mail. Now I explored a bit more what -Xd can do for us here and if I use it, then it will add both crtn.o and crtbegin.o from the ndk r5 and the application seams to work just the same. Now I also see that there are many folders from which to choose from with many different sets of .o files.

I am quite confused about why there are so many .o files, what each of them does and which ones should be linked into the library. Unfortunately the ndk documentation is much worse then the sdk documentation. It isn't even available online for browsing.

In our previous episode, Felipe Monteiro de Carvalho said:

Browse through the below thread, mainly my and Jonas posts:

http://lazarus.freepascal.org/index.php/topic,8084.msg57377.html#msg57377