[gambit-list] trying to make Blackhole work with Android

Mikael mikael.rcv at gmail.com
Mon Jan 9 18:26:44 EST 2012


Hi Alvaro,

First, before making BH work on a particular platform, doublecheck that
Gambit works on it in itself. As you're aware, this is a pre-requirement.

Does Gambit work on Android, for you? If so, what configuration did you use?

What's your current goal, to get a complete environment with compilation
and all running on the Android, or solely to make your Linux machine
produce binaries runnable on the Android (including a REPL with
interpreter)?


For resolving any compilation-related issues, you want Gambit to be verbose
to you about exactly what C compiler and linker invocations it does,
including all parameters passed.

Gambit invokes the C compiler and linker from the gambc-cc shellscript, and
this script is verbose - outputs any C compiler and linker calls to the
console - if it's run with the environment variable GAMBC_CC_VERBOSE set.

Thus, when starting the gsc you'll use for producing Android binaries, run
it like this from bash: GAMBC_CC_VERBOSE=yes gsc


Now zooming in a bit on BH:

I'm generating all 5 files like BH usually does.
> These 4 files are the part of Blackhole I understand least, but they are
> all needed for the module to be defined in C. According to Per:
>
> "When compiling modules for use in development (as opposed to "bh exe"),
> Black Hole works internally by compiling every module into *4* Gambit
> modules (c files if you will):
>
> 1) runtime code
> 2) compiletime code (this is essentially the same code as the runtime
> code, but does not use the global namespace and is thus slower but it's
> required to be able to create an unbound number of instances of the same
> module at any given time)
> 3) visit-time code (these are the macros)
> 4) module metadata (this is pretty much a compiled a-list)
>
> If you want to retain the development information, you will need 4 .c
> files per Black Hole module. If you want to strip development information,
> you will only need one (the runtime code)."
>
> I'm trying both with the 4 files and the only one option.
>

This is a good time to clarify, what's your goal within the following scope:

Basically, for code execution, only the runtime code C file is needed.
(view this as the 'executable code' file.)

The total set of four files is needed to get a complete BH dev environment
running. The reason for more than one file, is because BH needs to have
several instances of each module "at hand", in order to get the macro
expansion spinning the right way. The syntactic tower version of BH
implements (exactly that;) the syntactic tower, appropriately and
correctly, and this requires more than one instance of the module to be
done the right way.

Thus, if your objective is to generate code that should be executable on
the target environment and that's it, go with one file, otherwise go with
all four.

Which of these two - exec only or complete dev environment - is your
current usecase?



Now into details about your issue:

 (A)

> The multiple definition of symbols happens in both situations, but
>
(B)

> an undefined reference happens for each one of the 3 files (I think that
> is due to the link file referencing them, I could take care of that). But
> the core of the problem is with the multiple definition
> of ___G_list, ___S_list, ___G_void and ___S_void
> How can this happen?
>

Is your point that (A) happens for either of the four files, while for the
last three files (B) happens as well?

Producing and compiling with link files is indeed a bit tricky. To the best
of my knowledge, the procedure to follow is something like this:

Make BH output C code:

(module-compile! 'yourmod to-c: t)

Now, for each of the C files you want to compile:

(link-flat '("yourmod.exact-c-file-filename") output: "
yourmod.exact-c-file-filename.o1.c")

Then compile:

(include the other arguments your gsc passes to gcc, as per the advice at
the top)
gcc yourmod.exact-c-file-filename yourmod.exact-c-file-filename.o1.c -o "
yourmod.exact-c-file-filename.o1"

you could give a shot with:

g++    -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -O1
-fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -rdynamic -shared
-I"/usr/include/"  -D___DYNAMIC yourmod.exact-c-file-filename
yourmod.exact-c-file-filename.o1.c -o "yourmod.exact-c-file-filename.o1"




> I attach the generated files. In order to try it, you can just use:
> g++ test.o1.c test-ct.c test-rt.c test-vt.c test-mi.c -lm -lutil -ldl
> -lgambc -o test.o
> ...and you'll get an (expected) undefined reference to main and all the
> multiple definitions I talk about.
>

Check with the suggested g++ use above, any improvement?


Best regards
>

Mikael


>
>
>
> On Sun, Jan 8, 2012 at 8:00 PM, Mikael <mikael.rcv at gmail.com> wrote:
>
>> As to make BH compile to C rather than object files, pass to-c: #t to
>> module-compile! .
>>
>> What's the first 4 of the 5 files you mention below? (Format, content,
>> when needed / scope of use, and so on)
>>
>> The link file is produced by BH at some point (presuming by link file you
>> mean link file as per Gambit's definition). To make a C link file out of
>> Gambit, I don't remember, either there's a special BH procedure for it, or
>> you do it the general way it's done in Gambit, please let the ml know what
>> you got to, and if it's not obvious please query again.
>>
>> Mikael
>>
>> 2012/1/8 Álvaro Castro-Castilla <alvaro.castro.castilla at gmail.com>
>>
>>>  Hi!
>>>
>>> I'm trying (again) to make Blackhole work with Android. For that purpose
>>> I need to make it compile to C, instead of its normal *.o files. BH needs
>>> to compile 5 files for each module:
>>> - a compile-time file
>>> - a real-time file
>>> - a visit-time file
>>> - a module metadata file
>>> - the link file
>>>
>>> Based on https://github.com/seoushi/gambit-android-example but using
>>> the newer "Native Activity" I'm trying to compile an example. First, I'm
>>> trying to compile an example with just one file, importing no modules.
>>>
>>> I'm getting:
>>>      [exec] ./jni/ext/libgambc.a(_gambc.o):(.data+0x4854c): multiple
>>> definition of `___G_list'
>>>      [exec]
>>> ./obj/local/armeabi/objs/native-activity/main.o1.o:(.data+0x3c): first
>>> defined here
>>>      [exec] ./jni/ext/libgambc.a(_gambc.o):(.data.rel+0x13708): multiple
>>> definition of `___S_list'
>>>      [exec]
>>> ./obj/local/armeabi/objs/native-activity/main.o1.o:(.data.rel+0xb0): first
>>> defined here
>>>      [exec] ./jni/ext/libgambc.a(_gambc.o):(.data+0x5ae40): multiple
>>> definition of `___G_void'
>>>      [exec]
>>> ./obj/local/armeabi/objs/native-activity/main.o1.o:(.data+0x54): first
>>> defined here
>>>      [exec] ./jni/ext/libgambc.a(_gambc.o):(.data.rel+0x19138): multiple
>>> definition of `___S_void'
>>>      [exec]
>>> ./obj/local/armeabi/objs/native-activity/main.o1.o:(.data.rel+0xe0): first
>>> defined here
>>>
>>> I would like to know if any of you had similar experiences, and why I'm
>>> getting this multiple definitions? The link file (called main.o1.c) seems
>>> to redefine these symbols, but they are also defined in libgambc.a (which
>>> is compiled for ARM architecture)
>>> Why could this be happening?
>>>
>>> I'd appreciate any pointers. Thanks a lot for your help,
>>>
>>> Álvaro Castro-Castilla
>>>
>>> _______________________________________________
>>> Gambit-list mailing list
>>> Gambit-list at iro.umontreal.ca
>>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20120110/516369e3/attachment.htm>


More information about the Gambit-list mailing list