Re: [Gc] compiling gc-7.2alpha2 or a4
ivmai at mail.ru
Tue Dec 8 09:51:03 PST 2009
"Marcos Dione" <Marcos_David.Dione at sophia.inria.fr> wrote:
> On Mon, December 7, 2009 8:00 pm, Ivan Maidanski wrote:
> > Marcos_David.Dione at sophia.inria.fr wrote:
> >> 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:
> >> ...
> > This was my idea to add this android-specific code (the code really looks
> > the same as in mono).
> can you please point me to the mono code you mention? also, do you
> know against which version of the android platform (1.0, 1.5 cupcake,
> 1.6, 2.0) did they compiled against? I forgot to mention it, but I'm
> trying 1.5 cupcake here.
For a mono link, search for "PLATFORM_ANDROID" and "mono" in google codesearch.
Now, I remember I successfully compiled GC on NDK 1.5r1 (but this was toolkit for windows development host which doesn't define __linux__ (which is tested by GC)).
Now, this is fixed and should work for any toolkit (I've tested with v1.6r1).
> > 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.)
> hmm, koushik dutta seems to have exploited mono's ability to
> produce java code, because he uses the NDK for the port.
> >> 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?)
> I also forgot to mention which version of gc I'm using: it's
> gc-7.2alpha4. and no, this is gc's code.
> > IMHO, you'd probably try to
> > build/run a test without -ldl first (as Hans suggested above).
> you mean, compiling statically?
Discard this suggestion.
> On Tue, December 8, 2009 11:40 am, Marcos Dione wrote:
> > On Mon, December 7, 2009 8:00 pm, Ivan Maidanski wrote:
> >> Marcos_David.Dione at sophia.inria.fr wrote:
> >>> 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?)
> > I also forgot to mention which version of gc I'm using: it's
> > gc-7.2alpha4. and no, this is gc's code.
> duh, I see that I'm mistaken here. actually this piece of code is from
> a post in japanese (which unluckily I can't read) that seems to
> explain something related to the original problem: link.h is not
> there. In any case, -DLINUX -DPLATFORM_ANDROID does not work.
I'd been looking at that page right at the moment when received this letter.
>  https://android.g.hatena.ne.jp/n4_t/20090704/1246689974
> On Tue, December 8, 2009 12:38 pm, Marcos Dione wrote:
> > beh, actually this was my mistake. the patch I mentioned before? it
> > was only partially applied. in any case, both define
> > SEARCH_FOR_DATA_START, which then defines NEED_FIND_LIMIT, which asks
> > for JMP_BUF GC_jmp_buf. applying the rest of the patch fixed it, but
> > I'm still in the point of:
> > /auto/sop-nas2a/u/sop-nas2a/vol/home_indes/mdione/src/works/inria/android/live/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
> > all the modifications I made to the code so far are in the attached
> > patch. I will try only with naoya_t's patch and then with my part of
> > the patch alone to see what happens.
> ok, I tried them all. in one or another way I hit the same error:
> undefined reference to `__stack_base__'. as I mentioned before, this
> seems to be normally defined in crt0.o, but the toolchain does not
> provide such a file. I'm not sure that this will be fixed by compiling
> statically (and in any case the result won't be useful to me; I will
> need the dynamic version for later compiling another tool based on
> bigloo). any hints?
Try the latest version from BDWGC CVS (I've added some workarounds for Android (some of them are as you sent to me).
1. To compile for Android you should use -DPLATFORM_ANDROID (you know this - just for clarity).
2. To build without dynamic libraries registering, use also -DIGNORE_DYNAMIC_LOADING.
3. Alternatively, to build with that support, get and include bionics clib linker headers.
If you would still experience linkage problems, send me the linkage command (that is passed to gcc).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4161 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20091208/62b95588/bdwgc-ivmai-223.obj
More information about the Gc