Re[2]: [Gc] compiling gc-7.2alpha2 or a4

Ivan Maidanski ivmai at mail.ru
Mon Dec 7 11:00:47 PST 2009


Marcos_David.Dione at sophia.inria.fr wrote:
> On Fri, December 4, 2009 10:51 pm, Boehm, Hans wrote:
> > I know almost nothing about Android, but it looks to me like the absence
> > of link.h
> > is a real issue.  The garbage collector normally walks the dynamic
> > loader's data structures with dl_iterate_phdr.  That interface is normally
> > declared in link.h.
> >
> > If it doesn't exist (try a grep in /usr/include), the other options are
> >
> > - link statically, and don't define DYNAMIC_LOADING
> >
> > - define USE_PROC_FOR_LIBRARIES and find roots using /proc.  That may be
> > suboptimal, and I'm not sure that interface is supported either.
>
>     hi hans. tx for the answer. it was a good tip, but I'm confused on
> what I found.
>
>     android is not a nice place to be if you're going native. actually
> they don't support native ports besides what you can get with the NDK,
> but I'm actually trying to do exactly that. so, what I found:
>
>     I don't know (I really don't, all this is completely new to me) if
> this is normal, but bionic, the crippled code that passes for a libc
> in the android platform has stubs functions in its libld code:
>
> http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=libdl/libdl.c;h=7971942a7571994c8f616de50394bff74150e497;hb=HEAD
>
>     then it happily does some black magic I don't understand, and whose
> only explanation is this:
>
> /* This file hijacks the symbols stubbed out in libdl.so. */
>
>     you can find that pearl (not perl, luckily) here:
>
> http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=linker/dlfcn.c;h=039926c737aa0242425f6b3a3bb655fc83a3b3d8;hb=HEAD#l21
>
>     as you can see that file loads a linker.h, which I promptly included
> wrapped around some #ifdefs and some more and the beast seems to
> compile with this commands:
>
> $ export CFLAGS="-DLINUX -DPLATFORM_ANDROID"
> $ ./configure --host=arm-linux-gnulibc
> $ make
>
>     it compiles all right, but then if I try to link something against it
> (in my case, I'm trying to compile bigloo, which I mentioned in my
> previous post) I get this:
>
> [...]/bigloo3.3a/lib/3.3a/libbigloogc-3.3a.a(os_dep.o): In function
> `GC_get_main_stack_base':
> os_dep.c:(.text.GC_get_main_stack_base+0x1c): undefined reference to
> `__stack_base__'
> collect2: ld returned 1 exit status
>
>     the problem with __stack_base__ (I think) is that the android platform
> does not have a crt0.o where this symbols is normally defined.
>
>     so my first conclusion is that -DLINUX and -DPLATFORM_ANDROID are not
> meant to be mixed. I just took this idea from gcconfig.h, around line
> 1839 where you can read:
>
> [...]
> #   ifdef LINUX
> [...]
> #       ifdef __ELF__
> [...]
> #            if defined(__GLIBC__) && __GLIBC__ >= 2 \
>                 || defined(PLATFORM_ANDROID)
> #                define SEARCH_FOR_DATA_START
> [...]

This was my idea to add this android-specific code (the code really looks the same as in mono).
I don't remember whether I compiled GC for the target (most probably not), I has very little experience with compiling C for NDK (and even less linking one which I found a bit complicated compared to other embedded toolkits). (I also found&reported a missing proto in a clib header but this was unrelated to GC.)

>
>     but later around line 1869:
>
> [...]
> #   ifdef PLATFORM_ANDROID
> #        define SEARCH_FOR_DATA_START
> #     undef NOSYS
> #   endif
> [...]

This absent in the GC CVS (probably, you refer to Mono code, right?)

>
>     so I tried without -DLINUX, but it doesn't compile:
>
> libtool: compile:  /usr/local/bin/droid-gcc [...] -c allchblk.c -o
> ..libs/allchblk.o
> In file included from allchblk.c:17:
> ../include/private/gc_priv.h:2190: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'GC_jmp_buf'
>
>     this clearly means that JMP_BUF is not defined. I see that some lines
> early (around line 2134) it is defined for different situations, but
> then I don't know which is the right for me or if it's another
> situation at all. if I define UNIX_LIKE, I go back to the previous
> situation, so I'm completely lost again.

You could also try to guard that error place with ifndef JMP_BUF if [sig]jmp_buf is not refered from another place (but, of course, successful compilation doesn't mean it would work). IMHO, you'd probably try to build/run a test without -ldl first (as Hans suggested above).

>
>     as I said all this is completely new to me, but then I'm paid to do
> it, so any hints on how to proceed will be thoroughly followed. I
> tried to read the porting document but right now is english mixed with
> klingon.

Patches are welcomed ;)

>
> --
> Lic. Marcos Dione
> Engineer Expert - Hop Project
> http://hop.inria.fr/
> INRIA Sophia Antipolis - MИditerranИe
> Phone: +33 (0)4 92 38 79 67

Bye.


More information about the Gc mailing list