On Thu, 30 Dec 2010 10:42:43 +0100 Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote:
Sorry that I didn't read the previous discussions, which most probably happened on another list (and it's unclear to me why OpenAxiom requires that implementation-dependent low-level information; why it cannot use an FFI library or standard means such as CL min/max constants such as MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM to obtain the information it needs); I'll simply suggest ideas about what I know, hoping they weren't discussed or dismissed already. You may cross-post or quote from this message as wanted. > I sincerely have no idea how to provide this ABI stuff. The only pieces of > information that ECL has are C integer sizes (EXT:C-UINT-MAX, > EXT:C-ULONG-MAX, etc) If someone may infer the appropriate ABI name and > compiler flags from it, then it is ok, but I do not know how to get that. Is GNU binutils/objdump capable of distinguishing the various ABIs properly from a given object file (i.e. especially in the cases you mentioned where there may be multiple 32-bit and/or 64-bit options on the same host)? An awkward runtime ABI detection idea: If that works, perhaps that we could either copy the method it uses and include it in a library built with ECL, or include such a tool as part of the ECL toolchain, for it to at start-time optionally create a temporary object and infer its ABI, adding the relevant keywords to *FEATURES*. Even if that worked though, it has its issues: - Dependency on GNU toolchain components or equivalent portable code such as objdump/readelf/file - ECL process must compile and write a file somewhere on the file system to determine the ABI - Even if that was done and worked at startup, the information in *FEATURES* would be outdated if CL code changes CFLAGS and/or LDFLAGS at runtime - Meaning that it might be best to provide a special function to infer the ABI instead of providing the information in *FEATURES*, which function would most probably be used by software also expecting to use the compiler, which would also no longer require ECL to need to compile and write to the file system at startup. - If all that complexity is needed, couldn't the third party configuration script itself ensure to build the CL implementation (ECL in this case) and any other tools it requires together using a compatible ABI to avoid the problem? Or allow/require the user to specify the target ABI at project compilation time if they cannot be derived from the existing CL implementation alone, and package maintainers scripts could pass that parameter if they chose an implementation such as ECL for their project... (or see below) > Alternatively I am being asked to provide whether ECL is built with 64-bits > or 32-bits. I argue that this information is not enough to infer compiler > flags, for some platforms do provide more than two choices (different 32-bit > modes, different 64-bit modes, incompatible among them). Furthermore what I agree, if going in the direction of runtime tests without needing external tools, by some heuristics we indeed could coarsely distinguish between little endian and big endian, 32-bit and 64-bit among very common ABIs, but I'm sure there always will remain cornercases indeed, especially that ECL allows CFLAGS/LDFLAGS manipulation, which as you said is a useful feature of ECL and on some toolchains/systems could change many things. > ECL does is simply to choose the largest integer that fits a pointer and > work with that as a fixnum, be it int, long or long long. So there is no > notion of 64-bit or 32-bit, it is just what the system gives, and I am not > sure that this may be used to identify the ABI. If it does, it can be > gathered in a simple way > ecl -eval '(print (* 32 (round (/ (integer-length most-positive-fixnum) > 32))))' -eval '(quit)' > I understand that this solution is rejected because I am asked to offer a > 100% relation between this number and the ABI which, as I said, I do not > feel comfortable to do that. > > It has been repeatedly argued that ECL does know the ABI and that all we are > doing is hiding it and producing an uncooperative library that does not > allow itself to be properly linked against other software. This is not the > image I want to transmit and as you may argue I have no intention to be > resistive against futher uses of ECL, but I sincerely do not know what I am > expected to do. Static ABI idea with optional CC/CFLAGS/LDFLAGS for advanced users: It might be possible to (optionally, if need be), determine the ABI at ECL build time (the one used to build ECL itself, probably also the native toolchain's) and have the necessary information exported as *FEATURE* keywords, and have ECL runtime ignore by default custom CC/CFLAGS/LDFLAGS (thus compatible ABI objects would always be generated) unless ECL would be told to honour them by an advanced user (with all the risks it entails) using a startup flag, configuration file option or something akin to package locks, but related to ABI enforcement... Possibly that the related *FEATURE* ABI keywords could also no longer appear when the ABI-LOCK is released. This also has potential drawbacks: - ECL itself might ignore the ABI specifics if it doesn't need them, but does those *FEATURE* keywords alone satisfy OpenAxiom requirements? - Determining the toolchain's native ABI at ECL build time - A lock advanced users must now release to enable custom compilation/linking flags After doing a few searches to find out if autoconf reliably can detect the ABI, it seems that various libraries (such as GMP) require it to be provided at build-time instead of detecting it. binutils/objdump could possibly help, but it would again become a build-time dependency on a GNU toolchain component. Another possibility would be to add an (or a few) ABI related option(s) to ECL configure script and if supplied, enable the ABI-LOCK and export those extra *FEATURE* keywords, leaving ECL package maintainers the responsibility to supply it, like for GMP... ECL behaving as it does today if they're not specified. But again: if ECL itself ignores the ABI at runtime but exports the needed *FEATURE* keywords and provides CL standard min/max constants, while by default ensuring that custom CC/CFLAGS/LDFLAGS get ignored, does this satisfy OpenAxiom building requirements? -- Matt ------------------------------------------------------------------------------ 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