trying to build a cross-compiler that will run fortran on Android device - but getting link error as it looks for crt0.o

[steve kirby]

Greetings,

 

In an effort to build a cross-compiler using GCC, so I can have gfortran to compile code for use on an Android device, I have hit on a link problem. 

 

(1)Here's my configuration step:

../gcc-4.8.2/configure --prefix=/home/skirby/ANDROID19 --target=arm-android-eabi --with-gnu-as --with-gnu-ld  --enable-languages=c,fortran --with-mpfr=/home/skirby/ANDROID19 --with-gmp=/home/skirby/ANDROID19 --with-mpc=/home/skirby/ANDROID19 --disable-nls --disable-tls  --disable-bootstrap  --disable-libgomp --disable-shared --disable-libssp --disable-libquadmath --enable-threads --with-arch=armv5te --enable-target-optspace--with-sysroot=/home/skirby/android-ndk-r9b/platforms/android-19/arch-arm

 

(2) gmake runs for quite a while, then dies with this:

checking whether symbol versioning is supported... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
gmake[1]: *** [configure-target-libgfortran] Error 1

 

(3) then, to trace the error more specifically, I look at config.log in ~/gcc-build/arm-android-eabi/libgfortran, which shows:

/home/skirby/ANDROID19/arm-android-eabi/bin/ld: cannot find crt0.o: No such file or directory
/home/skirby/ANDROID19/arm-android-eabi/bin/ld: cannot find -lg
collect2: error: ld returned 1 exit status

 

(4) I can't find crt0.o anywhere.  Is there a workaround?  As far as the -lg issue, where would a libg.a be found?

 

(5) alternatively, in searching the web, for users with this same issue, I saw this mentioned: "the best thing to do is to use make-standalone-toolchain.sh instead of trying to use the binaries directly from $NDK/toolchains/arm-linux-androideabi-4.4.3/.../".  Can anyone give me a quick pointer on how to use this script as opposed to way I've done things above?

 

TIA,

steve

 

[Steve Ellcey]

On Fri, 2014-01-10 at 09:15 -0800, steve kirby wrote:

> (3) then, to trace the error more specifically, I look at config.log
> in ~/gcc-build/arm-android-eabi/libgfortran, which shows:
> /home/skirby/ANDROID19/arm-android-eabi/bin/ld: cannot find crt0.o: No
> such file or directory
> /home/skirby/ANDROID19/arm-android-eabi/bin/ld: cannot find -lg
> collect2: error: ld returned 1 exit status
>
> (4) I can't find crt0.o anywhere. Is there a workaround? As far as
> the -lg issue, where would a libg.a be found?

Rather then find crt0.o and libg I think you need to stop the configure
script from doing the links. If you look at libgfortran/configure.in
you will see this code:

# Check for library functions.
if test "x${with_newlib}" = "xyes"; then
# We are being configured with a cross compiler. AC_REPLACE_FUNCS
# may not work correctly, because the compiler may not be able to
# link executables.
AC_DEFINE(HAVE_MKSTEMP, 1, [Define if you have mkstemp.])
AC_DEFINE(HAVE_STRTOF, 1, [Define if you have strtof.])
AC_DEFINE(HAVE_SNPRINTF, 1, [Define if you have snprintf.])
AC_DEFINE(HAVE_STRCASESTR, 1, [Define if you have strcasestr.])
AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.])
AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.])
AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.])

# At some point, we should differentiate between architectures
# like x86, which have long double versions, and alpha/powerpc/etc.,
# which don't. For the time being, punt.
if test x"long_double_math_on_this_cpu" = x"yes"; then
AC_DEFINE(HAVE_STRTOLD, 1, [Define if you have strtold.])
fi
else
AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
alarm access fork execl wait setmode execve pipe dup2 close \
strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
readlink getgid getpid getppid getuid geteuid umask getegid \
secure_getenv __secure_getenv mkostemp)
fi

I think that if you configure with --with-newlib and/or tweak this code so that
the if statement is true even without with_newlib being set then the configure
will set the various HAVE_* variables without doing any links and you may be
able to build. (Obviously, If you change configure.in you will need to regenerate
and/or make the same change in configure.) Depending on what functions Android
actually supports you may need to change what HAVE_* variables are set in the if
statement.

Steve Ellcey
sel...@mips.com

[David Turner]

I suggest trying using --target=arm-linux-androideabi instead, with the NDK's standalone toolchain in your path.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-ndk.
For more options, visit https://groups.google.com/groups/opt_out.

[steve kirby]

Thanks so much for your very fast responses, Steve and Digit,  to my issue - here's what I've found out in further testing:

 

(1) I first tested Digit's suggestion, i.e., change the target to "arm-linux-androideabi".  This got me a lot farther in the compilation, but ends with this: "configure: error: Pthreads are required to build libatomic.  [configure-target-libatomic] Error 1"

 

(2) went ahead and then added Steve's suggestion, i.e., adding "--with-newlib" flag to the configure call, but get same error as in (1).

 

(3) checking the config.log under libatomic, I see errors like:

 "/home/skirby/gcc-build/arm-linux-androideabi/libatomic/conftest.c:40: undefined reference to `__atomic_store_8'

 collect2: error: ld returned 1 exit status

"

 

Any idea on how to get around the error I list in (1)?

Do I need to build a Pthreads library and reference it in the configuration call?

 

(4) as an aside, I found, at http://osdir.com/ml/android-ndk/2012-12/msg00111.html, this line: "The error message "error: Pthreads are required to build libatomic"
Happens when building the ARM version of gcc-4.8 downloaded from gnu.org,
better stay with Google's GCCs."

 

Which leads me to the question: Is there a source GCC other than the one from GNU, i.e., a "Google GCC", as he references?  If so, do you recommend I use it to circumvent this pthreads problem?  And the key question: if a "Google GCC" exists, where can one obtain it?

 

TIA,

Steve

[steve kirby]

Forgot to add one thing, and not sure if it's relevant to the libatomic/pthreads issue I outlined earlier -

 

In my gcc configure flags, I have "--with-arch=armv5te".  This I realized I blindly put in as I was going off of Mike Long's blog from about 2 yrs ago, for building gfortran for the android.  I have an HTC One Android.  How can I determine what processor it has, so I can get it right for the configure flags?

 

TIA,

Steve

 

On Friday, January 10, 2014 10:15:00 AM UTC-7, steve kirby wrote:

[steve kirby]

Per my issue of the cross-compile stopping, as mentioned above, "configure: error: Pthreads are required to build libatomic" -- Much to my embarassment, Steve E., I realized I had not built newlib (the C library for embedded systems) before adding the --with-newlib in the configure. 

 

When I do try this, maybe I can give, for the newlib configure, the proper flags so it has pthreads built in? 

 

TIA,

Steve

On Friday, January 10, 2014 10:15:00 AM UTC-7, steve kirby wrote:

[Steve Ellcey]

On Fri, 2014-01-10 at 14:54 -0800, steve kirby wrote:
> Per my issue of the cross-compile stopping, as mentioned above,
> "configure: error: Pthreads are required to build libatomic" -- Much
> to my embarassment, Steve E., I realized I had not built newlib (the
> C library for embedded systems) before adding the --with-newlib in the
> configure.
>
> When I do try this, maybe I can give, for the newlib configure, the
> proper flags so it has pthreads built in?
>
> TIA,
> Steve

I don't know if you actually want to build newlib, it looks like you
already have a libc, etc, sysroot set up
in /home/skirby/android-ndk-r9b/platforms/android-19/arch-arm. The only
reason to set --with-newlib was to take the other branch of the if
statement in the libgfortran configure script. (I am not sure if using
it would have any other affects or not.) So I would just
reconfigure/rebuild GCC with this option and see if it helps with the
libgfortran library build. If not, then it may not be something to
pursue.

Steve Ellcey
sel...@mips.com

[David Turner]

The libatomic configure script is probably trying to link a test program with -lpthread, but there is no libpthread.so on Android (all features are provided by the C library, which makes a lot more sense these days). Can you check the config.log file for it, it will have more details.

If so, you could try to add an empty libpthread.a to your standalone toolchain sysroot, that should probably be enough to get past this.

Hope this helps.

--

[steve kirby]

Thanks Steve for the good info.  I can compile newlib, include it in the configure flags, and see if it helps out or not.  Hadn't heard about newlib until today so this is definitely illuminating.

--
You received this message because you are subscribed to a topic in the Google Groups "android-ndk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-ndk/iLjDgFZfWac/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-ndk...@googlegroups.com.

[steve kirby]

Thanks David for the pointer.  Indeed, in checking the config.log under libatomic I'm seeing two -lpthread attempts.  I'll test what you suggest regarding the empty libpthread.a.

 

On a broader note, the fortran code I want to compile using my soon-to-be-ready :> gfortran cross-compiler, works much better if it can access any parallelism available on my HTC one.  I assume it has one ARM processor but don't know yet?  If that's the case, how can one build the cross-compiler so it can handle code designed to run on one node (SMPAR mode)?  Something like OpenMP...

 

I really need to bone up on this phone, having just having it handed to me at work!

 

TIA,

Steve

--
You received this message because you are subscribed to a topic in the Google Groups "android-ndk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-ndk/iLjDgFZfWac/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-ndk...@googlegroups.com.

[steve kirby]

David/all -

 

the empty libpthread.a file did not work; the error was something about a truncated file as it had nothing to read.  I did get a 'successful' compile only when I used "disable-libatomic" in my configure script.

 

However, getting an error, testing the new gfortran compiler output ("cannot execute binary file") Should this be a new thread? anyway, I'll lay out my findings so far:

 

(1) my test program, "test.f":

program firsttest

print *,'this is a test'

end

(2) generate assembler code

 ~/ANDROID19/bin/arm-linux-androideabi-gfortran -S test.f

(3) generate machine code

 ~/ANDROID19/bin/arm-linux-androideabi-as -o test.o test.s

(4) link

~/android-ndk-r9b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld -o test.exe test.o  -L/home/skirby/ANDROID19/arm-linux-androideabi/lib/armv7-a -lgfortran -L/home/skirby/ANDROID19/lib/gcc/arm-linux-androideabi/4.8.2/armv7-a -lgcc -L/home/skirby/android-ndk-r9b/platforms/android-19/arch-arm/usr/lib -lc

(5) ./test.exe

./test.exe: cannot execute binary file

(permissions are 755 so it's not a permissions problem)

 

looking further:

(a) file ./test.exe

./test.exe: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

(b) ldd ./test.exe

not a dynamic executable

(c) uname -a

Linux *.*.* 3.11.8-200.fc19.x86_64 #1 SMP Wed Nov 13 16:29:59 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

 

I should be able to run a 32-bit executable on a 64-bit machine right? (I know the reverse is a problem)

 

TIA for any advice,

Steve

 

[David Turner]

You can't run an ARM binary on a Linux x86_64 machine :-) You need to run the program on a device, or an emulator.

[steve kirby]

thanks David.  I'll try an emulator first.

 

--Steve