<div dir="ltr">Hi Julien,<br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br></span>
I have been thinking about how to do this: we could have a new script in<br>
tools, (e.g. tools/configure_arm_linux_cross) and then add a new option<br>
to the configure script, --with-host-execs, which would cause it to<br>
install the executables from the host system rather than build them from<br>
the target system.  The new option may as well disable compilation of<br>
the target executables as well since in that scenario all we care about<br>
is the libraries.<span class=""><br>
<br></span></blockquote><div><br></div><div>Sounds to be a good idea. Would that in principle allow using a bare metal toolchain? Now configure filters those out.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
True, although it's only significant if you wish your cross-compiler to<br>
able to compile things in the java grade.  However, since it's Java<br>
you may as well just compile on the host system and copy the .jars<br>
across.<br>
<br></blockquote><div> </div><div>Right. There seems to be no point enabling the Java back-end in the cross-compiler.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span>
They are probably statically linked, against the Mercury libraries if<br>
not the system ones.  Try compiling with "--mercury-linkage shared".<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Thanks for the suggestion... but the sizes remain the same. I tried --linkage shared as well.</div><div><br></div><div>--Vladimir</div><div><br></div></div></div></div>