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

Álvaro Castro-Castilla alvaro.castro.castilla at gmail.com
Tue Jan 10 04:04:26 EST 2012


Hi,

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?
>

Yes, it works in Gambit itself. I'm using ant. You can check the project
here:
https://github.com/alvatarc/bh-android-template/blob/master/jni/main.scm



> 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)?
>
>
I want to produce binaries to execute in Android. Cross-platform
development.



>
> 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.)
>
>
Yes, I'm aware of that, but if only this one is included, then you get one
symbol undefined per each one of the others, plus the same multiple
definitions.



> 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.
>
>
Ideally, I only need the rt version, but I still need to check if there is
interest in including the others (when debugging code for android maybe? I
can't tell).


>  (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?
>
>
Yes, always.

For instance, there are a couple of needed changes for

(c-define (c-draw) () void "draw_scheme_hook" "" (~#draw-hook))
-this one is due to the bug in blackhole when expanding c-define-
and:

#define LINKER ____20_main_2e_o
instead of
#define LINKER ____20_main__

but the rest of main.scm is exactly the same code, only that Gambit vanilla
generates two files that work well (main.c and the link file main_.c).


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")
>
>
That's how BH is doing it, and how I'm doing it.
You can check my fork of Blackhole, that allows to compile to C via the
command-line:
bh compile -C module.scm
(it uses the modern syntactic tower version, but it has a few bugs)
Currently it doesn't work if you use forms that force compilation, such as
any FFI c-define, c-declare etc. But for testing purposes a module with
(define (double x) (* 2 x)) suffices.



> 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"
>
>
That works, but that's expected: the issue with multiple symbol definition
happens against libgambc.a, which you don't link here. But it is needed for
any standalone executable, and that's when it fails.
I've made a quick README, in case you want to test the Android template I'm
working on.

I'll further check any possible differences between BH-generated files and
Gambit/vanilla-generated files.
Thanks a lot for your help and interest.

Best regards,

Álvaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20120110/e0251d72/attachment.htm>


More information about the Gambit-list mailing list