On Sat, Jan 1, 2011 at 2:23 PM, DS <e...@sol42.com> wrote: > > On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote: > >> Anyway, I do no believe that the suggestion for ECL to make available > >> its binary flavor is equivalent to building and maintaining a database > >> of all imaginable ABIs and all combinations of processors. > > > > I believe Juanjo was referring to the second obvious way to figure out > system info from C: conditional compilation. In that case the C code > would be sort of like
There usually are many ways to implement a specification. That does not necessarily mean we have to reject the specification just because, among the many possible implementations, we have found one that we don't like :-) > and you have to know the exact symbol used by every supported platform: > some are lowercase, some are uppercase and have underscores, etc. Same > for system version and architecture. This would be the database Juanjo > does not want to build and maintain, and I find that understandable. yes, but is a completely different issue and I don't see how that would implement the binary information in question. The issue is to tell the binary flavour of the ecl program or libecl library. This is the same kind of binary information that a dumb linker would use to reject a binary file for not being compatible. Lest this analogy be misconstrued, I am emphasizing that I am not suggesting that ECL writes its own linker. I'm just saying that the binary information is one that comes from the RESULTING program or library, not the size of the C integer types used. > > BTW this is the only way to tell one C compiler from another from > 'inside' C that I know of. yes, but it is not reliable information and I'm not sure how that is necessary and why it implements the binary flavour of a program. > The first obvious way (for me at least) would be the uname() libc call, > but it is more limited and as far as I know is not present on some > platforms, so it would require an autoconf test. It is true that uname while being a POSIX function may not be present on all system, and even it is it may not give what we are looking for. Another way of thinking about this is that you are given binary objects to link together to construct a program. You do not have access to the original program. But, you can tell the binary flavour by just looking at the header of each binary object file -- that is in essence what `file' utility does, and that is a preliminary step of linkers. DISCLAIMER: I am not suggesting that ECL reimplements `file' or a linker. On POSIX systems, ECL can just issue `file test-program-linked-against-required-c-lib' and use the output to determine the binary flavour. On non-posix systems (not many, among the platforms where this actually matters.), it can have its own custom program to look at the header of the test program. Certainly using Autoconf's triplet in an improved way may remove the need to have to write custom header reading program. > Figuring out the ILP32/LP64/whatever bit is a matter of comparing > sizeof()'s. It is also easy to figure out endianness. This is very > simple and portable C code. Autoconf now has standard macros to test endianness at configuration time. At this point, I'm not asking for ILP32/LP64/LLP64 -- though I recognize that other ECL users want find it useful to have. > OTOH configure scripts usually do some or all of these tests. GMP is > extremely platform-dependant and surely knows about all this. Yes, definitely. > Extracting the information from there might be easier and more portable. Yes, that is what I suggested in private conversion. In fact, all it takes is just link a dummy C file against the GMP library and look at the binary flavour of the program as indicated above. I suspect that the `file' utility will handle most cases. Taking the Ruby interpreter I gave earlier, I have ring:~ gdr$ file `which ruby` /usr/bin/ruby: Mach-O universal binary with 3 architectures /usr/bin/ruby (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/ruby (for architecture i386): Mach-O executable i386 /usr/bin/ruby (for architecture ppc7400): Mach-O executable ppc The glaring case where `file' won't work is if compling on Windows using MS toolchain. In which case, we know we are dealing with PE/COFF binary file and we know how to get the information. For the rest, old UNIX `file' utility does the work. -- Gaby ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
