<div class="gmail_quote">On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">> Extracting the information from there might be easier and more portable.<br><br></div>Yes, that is what I suggested in private conversion.  In fact, all it takes is<br>just link a dummy C file against the GMP library and look at the binary<br>

flavour of the program as indicated above.  I suspect that the `file'<br>utility will handle most cases. </blockquote></div>
<div><br>The hardest point of the conversation, and one that people do not seem to get, is that I have no idea how to do this which is written in the paragraph and in the discussion before. Really, it makes the discussion very hard that people do not realize that I have no idea how to get binary information from an executable, or gather the binary mode from GMP just by linking a custom program -- to begin with, it would be utterly impossible to link against this library before having guessed the appropriate linker/compiler flags!</div>


<div> </div>
<div>Now, one might consider the possibilities that have been put forward here:</div>
<div> </div>
<div>* Deduce the binary mode from C macros. That is possible but requires keeping track of all possible operating systems that ECL might ship to, and their respective compilers, and then reverse-engineer the names to standardize them in some *features*. How to do that? I have never ever seen a database of compiler macros and their associations to compilers which can be reused.</div>


<div> </div>
<div>* Using POSIX utilities such as "file". AFAIK, the output of the file program is not standard (<a href="http://pubs.opengroup.org/onlinepubs/009695399/">http://pubs.opengroup.org/onlinepubs/009695399/</a>) and at most one could either output the raw names or do some translation.</div>


<div> </div>
<div>* Building some custom utility that inspects binary files.</div>
<div> </div>
<div>* Reverse engineering the CFLAGS supplied to ECL.</div>
<div> </div>
<div>* Autoconf triplets. ECL currently exports them as *features* and as the output of other functions but they do not work. They are unreliable and OS X, where OpenAxiom failed to build because of this, is an example.</div>


<div> </div>
<div>* Using uname. But this provides the same information as Autoconf, needs some parsing and I am not sure that it gives a different output for two binary files built differently running on the same OS -- for instance 32-bit and 64-bit applications --. Indeed I have seen 64-bit Solaris systems reported as i686 by command line uname.</div>


<div> </div>
<div>* Size of pointers. ECL provides this information via FFI. It is trivial to obtain and would work for most platforms I know and use personally (Windows right now, even with their ILP mode; OS X), but cannot guarantee that it distinguishes among other build modes (for instance PPC multiple floating point compilation modes)</div>


<div> </div>
<div>* Adding the features manually for a couple of platforms and forget about the rest. That would lead to a bunch of bug reports, if users do not get disgusted before because ECL is broken.</div>
<div> </div>
<div>...</div>
<div> </div>
<div>Now let's put this in context. Should OpenAxiom or any other ECL user want to link against a preinstalled GMP, or gnome library, would they demand that the library supplies this information? How would they obtain that information?</div>


<div> </div>
<div>This is the question that should be asked and answered, because ECL itself also suffers these problems with GMP itself -- being extremely platform dependent and having its own wild choices of build modes, with arbitrary naming, and no manual to decipher them, nor a way to gather the flags that GMP was built with... ECL simply assumes that either the user knows the way she built GMP and supplies the right CFLAGS, or lets ECL call GMP, configure it and cut&paste their CFLAGS/LDFLAGS (which I never found to be full of clutter).</div>


<div> </div>
<div>This seems to be the current attitude in the Autoconf'ed world, where uniform build environments are assumed and deviations from them are a responsibility of the packager or builder.</div>
<div> </div>
<div>So I am really lost here. Please accept this as a sincere statementand not some arbitrary resisitive attitude or an escape from a difficult problem as it might have been hinted privately and here.</div>
<div> </div>
<div>Juanjo</div>
<div> </div>
<div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com/" target="_blank">http://juanjose.garciaripoll.googlepages.com</a></div>