guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling for Android


From: beuc
Subject: Re: Compiling for Android
Date: Mon, 23 Jun 2014 20:59:07 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hey,

On Mon, Jun 23, 2014 at 09:59:24AM +0200, Ludovic Courtès wrote:
> address@hidden skribis:
> > Another issue: ./configure went well but I wasn't told iconv.h was
> > required:
> > ../../libguile/print.c:27:19: fatal error: iconv.h: No such file or 
> > directory
> 
> Hmm, could you run “grep -i 'iconv.h' config.log”?  There is a check for
> that, and normally Gnulib provides a replacement if needed.
> 
> Apparently lib/iconv.h doesn’t exist here, right?

Not if I don't install it.


[/me rebuilds the full environment with/without libs for the Nth time]

$ grep -i -C2 'iconv\.h' config.log  # tests excerpts removed
configure:7751: $? = 0
configure:7751: result: yes
configure:7751: checking for iconv.h
configure:7751: arm-linux-androideabi-gcc -c -g -O2  conftest.c >&5
conftest.c:70:19: fatal error: iconv.h: No such file or directory
compilation terminated.
configure:7751: $? = 1
--
configure:12557: checking for iconv
configure:12581: arm-linux-androideabi-gcc -o conftest -g -O2   conftest.c  >&5
conftest.c:124:19: fatal error: iconv.h: No such file or directory
compilation terminated.
configure:12581: $? = 1
--
| }
configure:12605: arm-linux-androideabi-gcc -o conftest -g -O2   conftest.c  
-liconv >&5
conftest.c:124:19: fatal error: iconv.h: No such file or directory
compilation terminated.
configure:12605: $? = 1
--
gl_cv_next_dirent_h='<dirent.h>'
gl_cv_next_fcntl_h='<fcntl.h>'
gl_cv_next_iconv_h='<iconv.h>'
gl_cv_next_langinfo_h='<langinfo.h>'
gl_cv_next_locale_h='<locale.h>'
--
NEXT_AS_FIRST_DIRECTIVE_FCNTL_H='<fcntl.h>'
NEXT_AS_FIRST_DIRECTIVE_FLOAT_H=''
NEXT_AS_FIRST_DIRECTIVE_ICONV_H='<iconv.h>'
NEXT_AS_FIRST_DIRECTIVE_LANGINFO_H='<langinfo.h>'
NEXT_AS_FIRST_DIRECTIVE_LOCALE_H='<locale.h>'
--
NEXT_FCNTL_H='<fcntl.h>'
NEXT_FLOAT_H=''
NEXT_ICONV_H='<iconv.h>'
NEXT_LANGINFO_H='<langinfo.h>'
NEXT_LOCALE_H='<locale.h>'


> > There's also an issue in libffi.pc where a '(libdir)' is copied
> > verbatim in LIBS, causing bash error at link time, which I hand-fixed
> > for now.
> 
> What does libffi.pc look like?

prefix=/usr/src/ndk-standalone-12-arm/sysroot/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
toolexeclibdir=$(libdir)
...
(instead of ${libdir})


> > In the end, I got a classical Android issue:
> >     CCLD     guile
> >   
> > /usr/src/ndk-standalone-12-arm/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld:
> >  ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o): in function 
> > scm_cancel_thread:../../libguile/threads.c:1175: error: undefined reference 
> > to 'pthread_cancel'
> >
> > ... classical because Bionic intentionally doesn't implement this function.
> 
> You could either comment out the related code in libguile, or build
> Guile --without-threads.

libguile-2.0 builds (yay!) and we start getting interesting errors:

make[2]: Entering directory '/mnt/workdir/guile/cross-android/module'
  GUILEC ice-9/eval.go
Backtrace:
In ice-9/boot-9.scm:
 157: 8 ;;; note: source file 
/home/personnel/workdir/guile/cross-android/../module/system/vm/frame.scm
;;;       newer than compiled /usr/lib/guile/2.0/ccache/system/vm/frame.go
;;; note: source file 
/home/personnel/workdir/guile/cross-android/../module/system/vm/program.scm
;;;       newer than compiled /usr/lib/guile/2.0/ccache/system/vm/program.go
;;; note: source file 
/home/personnel/workdir/guile/cross-android/../module/system/vm/instruction.scm
;;;       newer than compiled /usr/lib/guile/2.0/ccache/system/vm/instruction.go
;;; note: source file 
/home/personnel/workdir/guile/cross-android/../module/system/vm/objcode.scm
;;;       newer than compiled /usr/lib/guile/2.0/ccache/system/vm/objcode.go
;;; note: source file 
/home/personnel/workdir/guile/cross-android/../module/srfi/srfi-26.scm
;;;       newer than compiled /usr/lib/guile/2.0/ccache/srfi/srfi-26.go
[catch #t #<catch-closure 179d080> ...]
In unknown file:
   ?: 7 [apply-smob/1 #<catch-closure 179d080>]
In ice-9/boot-9.scm:
  63: 6 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 5 [eval # #]
 387: 4 [eval # #]
In srfi/srfi-1.scm:
 619: 3 [for-each #<procedure 1894f00 at scripts/compile.scm:179:14 (file)> #]
In scripts/compile.scm:
 182: 2 [#<procedure 1894f00 at scripts/compile.scm:179:14 (file)> 
"../../module/ice-9/eval.scm"]
In system/base/target.scm:
  57: 1 [with-target "arm-unknown-linux-androideabi" ...]
In unknown file:
   ?: 0 [scm-error misc-error #f "~A ~S" ("unknown CPU endianness" "arm") #f]

ERROR: In procedure scm-error:
ERROR: unknown CPU endianness "arm"
Makefile:2167: recipe for target 'ic


> Is the rest of pthreads implemented?  If yes, then we should add a test
> for pthread_cancel and arrange for that.

Apparently yes and that'd be the only missing function.
Check ./docs/text/system/libc/OVERVIEW.text from the Android NDK:

PThread implementation:

   Bionic's C library comes with its own pthread implementation bundled in.
   This is different from other historical C libraries which:

    - place it in an external library (-lpthread)
    - play linker tricks with weak symbols at dynamic link time

   The support for real-time features (a.k.a. -lrt) is also bundled in the
   C library.

   The implementation is based on futexes and strives to provide *very* short
   code paths for common operations. Notable features are the following:

      - pthread_mutex_t, pthread_cond_t are only 4 bytes each.

      - Normal, recursive and error-check mutexes are supported, and the code
        path is heavily optimized for the normal case, which is used most of
        the time.

      - Process-shared mutexes and condition variables are not supported.
        Their implementation requires far more complexity and was absolutely
        not needed for Android (which uses other inter-process synchronization
        capabilities).

        Note that they could be added in the future without breaking the ABI
        by specifying more sophisticated code paths (which may make the common
        paths slightly slower though).

      - There is currently no support for read/write locks, priority-ceiling in
        mutexes and other more advanced features. Again, the main idea being
        that this was not needed for Android at all but could be added in the
        future.

pthread_cancel():

   pthread_cancel() will *not* be supported in Bionic, because doing this would
   involve making the C library significantly bigger for very little benefit.

   Consider that:

     - A proper implementation must insert pthread cancellation checks in a lot
       of different places of the C library. And conformance is very difficult
       to test properly.

     - A proper implementation must also clean up resources, like releasing
       memory, or unlocking mutexes, properly if the cancellation happens in a
       complex function (e.g. inside gethostbyname() or fprintf() + complex
       formatting rules). This tends to slow down the path of many functions.

     - pthread cancellation cannot stop all threads: e.g. it can't do anything
       against an infinite loop

     - pthread cancellation itself has short-comings and isn't very portable
       (see http://advogato.org/person/slamb/diary.html?start=49 for example).

   All of this is contrary to the Bionic design goals. If your code depends on
   thread cancellation, please consider alternatives.

   Note however that Bionic does implement pthread_cleanup_push() and
   pthread_cleanup_pop(), which can be used to handle cleanups that happen when
   a thread voluntarily exits through pthread_exit() or returning from its
   main function.


pthread_once():

  Do not call fork() within a callback provided to pthread_once(). Doing this
  may result in a deadlock in the child process the next time it calls
  pthread_once().

  Also, you can't throw a C++ Exception from the callback (see C++ Exception
  Support below).

  The current implementation of pthread_once() lacks the necessary support of
  multi-core-safe double-checked-locking (read and write barriers).

-- 
Sylvain



reply via email to

[Prev in Thread] Current Thread [Next in Thread]