Hi,<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>




Does Gambit work on Android, for you? If so, what configuration did you use?<br></blockquote><div><br></div><div>Yes, it works in Gambit itself. I'm using ant. You can check the project here:</div><div><a href="https://github.com/alvatarc/bh-android-template/blob/master/jni/main.scm" target="_blank">https://github.com/alvatarc/bh-android-template/blob/master/jni/main.scm</a></div>




<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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)?<br>








<br></blockquote><div><br></div><div>I want to produce binaries to execute in Android. Cross-platform development.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<br>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.<br><br>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.<br>








<br>Thus, when starting the gsc you'll use for producing Android binaries, run it like this from bash: GAMBC_CC_VERBOSE=yes gsc<br><br><br>Now zooming in a bit on BH:<br><br><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">








<div>I'm generating all 5 files like BH usually does.</div>


<div>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:</div><div><br></div><div><div>"When compiling modules for use in development (as opposed to "bh exe"), Black Hole works internally by compiling every module into <b>4</b> Gambit modules (c files if you will):</div>











<div><br></div><div>1) runtime code</div><div>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)</div>











<div>3) visit-time code (these are the macros)</div><div>4) module metadata (this is pretty much a compiled a-list)</div><div><br></div><div>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)."</div>











</div><div><br></div><div>I'm trying both with the 4 files and the only one option. </div></blockquote></div><div><br>This is a good time to clarify, what's your goal within the following scope:<br><br>Basically, for code execution, only the runtime code C file is needed. (view this as the 'executable code' file.)<br>








<br></div></div></blockquote><div><br></div><div>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.</div><div><br>




</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>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.<br>








<br>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.<br><br></div></div></blockquote><div><br></div><div>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).</div>




<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> (A)</div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div>The multiple definition of symbols happens in both situations, but </div>



</blockquote></div><div>(B) <br></div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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</div>











<div>How can this happen?</div></blockquote></div><div><br>Is your point that (A) happens for either of the four files, while for the last three files (B) happens as well?<br><br></div></div></blockquote><div><br></div><div>




Yes, always.</div><div><div><br></div><div>For instance, there are a couple of needed changes for </div><div><br></div><div>(c-define (c-draw) () void "draw_scheme_hook" "" (~#draw-hook))</div><div>-this one is due to the bug in blackhole when expanding c-define-</div>




<div>and:</div><div><br></div><div>#define LINKER ____20_main_2e_o</div><div>instead of </div><div>#define LINKER ____20_main__</div><div><br></div><div>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).</div>




<div><br></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>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:<br>







<br>Make BH output C code:<br><br>(module-compile! 'yourmod to-c: t)<br><br>Now, for each of the C files you want to compile:<br><br>(<span>link</span>-flat '("<span>yourmod.exact-c-file-filename</span>") output: "<span>yourmod.exact-c-file-filename</span>.o1.c")<br>







<br></div></div></blockquote><div><br></div><div>That's how BH is doing it, and how I'm doing it.</div><div>You can check my fork of Blackhole, that allows to compile to C via the command-line:</div><div>bh compile -C module.scm</div>



<div>(it uses the modern syntactic tower version, but it has a few bugs)</div><div>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.</div>



<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Then compile:<br><br>(include the other arguments your gsc passes to gcc, as per the advice at the top)<br>



gcc <span>yourmod.exact-c-file-filename </span><span>yourmod.exact-c-file-filename.o1.c -o "</span><span>yourmod.exact-c-file-filename.o1"<br>



<br></span>you could give a shot with:<br><br>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 <span>yourmod.exact-c-file-filename</span> <span>yourmod.exact-c-file-filename</span>.o1.c -o "<span>yourmod.exact-c-file-filename</span><span></span>.o1"<br>






<span></span><br></div></div></blockquote><div><br></div><div>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.</div>



<div>I've made a quick README, in case you want to test the Android template I'm working on.</div><div><br></div><div>I'll further check any possible differences between BH-generated files and Gambit/vanilla-generated files.</div>

<div>Thanks a lot for your help and interest.</div><div><br></div><div>Best regards,</div><div><br></div><div>Įlvaro</div></div></div>