I think you are missing my point. The information I am talking about is used for *runtime* decisions - very likely in a script that is in a shared directory used by many different architectures.
While it may be one possible implementation to run a configure script at startup time, it quickly becomes more difficult (and expensive) to run it whenever a new process starts. Also, your goal may be a laudable long-term effort, but we need to evolve to that place; it won't happen overnight and forcing people (with the current behavior) to find alternate means to determine this information only slows progress toward the goal we both seem to have in common. And N people writing N different autoconf macros does not do much to "advance the art". H -- > Harlan Stenn wrote: > > > The differences between ALL of the various linux-gnu implementations are > > > so slight that they are far more suited to feature tests than something > > > like this. > > > > Are you really serious? ... > > > > - RC files? > > - packaging mechanism? > > - automount filesystem selection based on different OS versions? > > These are good examples for how autoconf may be useful: > - RC files: Check for the existence of /{etc,sbin}/{rc.d,init.d}. > - Packaging mechanism: Test for /bin/rpm and {/usr,}/bin/apt > - automount filesystem selection: Check for /afs. Check for > /etc/init.d/autofs or for autofs in /proc/modules. Check for amd... > > Remember: an autoconf macro is written once. A list of Linux distributions > that have a particular feature must be maintained forever. > > Bruno >