Ralf Wildenhues wrote: > I have a question regarding systems with more than one ABI, specifically > x86_64. If you consider for example the Debian distribution which has a > x86_64 kernel, but a completely x86 userland, Actually, that is one of the possibilities. And in that case I would deny that it is a completely x86 userland. 1. User installs x86 kernel. x86 userland. Everything 32-bit. I think this would be considered the "normal" installation. 2. User installs amd64 (aka x86-64) kernel. /usr/bin/ is x86 but can now run amd64 binaries too. So now the userland is a multiarch userland. 3. User installs amd64 (aka x86-64) kernel. /usr/bin/ is 64-bit amd64 binaries but the system can run 32-bit binaries too. Userland is a multiarch userland. > config.guess still gives you x86_64-unknown-linux-gnu as output. (I > have been told this, but not tried it myself). That is correct. The kernel returns x86_64 for 'uname -m'. The gcc toolpath is using x86_64 (with an underscore to avoid problems with the dash) as the architecture string. My understanding is that the kernel uses whatever gcc uses and returns that for 'uname -m'. > Now, if you configure a package and forget to add > --build=i686-pc-linux-gnu > or maybe use the setarch tool to set personality (I do not even know how > portable/available this is -- it exists in RedHat Fedora), it may break, > e.g. because of the __x86_64__ preprocessor define. I don't know about 'setarch' but you can use the 'linux32' program. It intercepts system calls and masquerades. (Note this works the same on ia64 too. But I will keep this to amd64.) uname -m x86_64 linux32 uname -m i686 linux32 bash uname -m i686 As you can see with that last you can run a larger userspace and lie to all of it about the current architecture. A user could use that as their normal environment and everything below that would believe it is a i686 system. > Would it not make more sense to have config.guess return i686 instead of > x86_64? I don't think that would be right. After all you are running an amd64 architecture at that point. The system can run 64-bit binaries. That is extremely important for some applications (such as mine :-). > Is it just too late to make that change now? How would it even > be possible to detect a completely 32bit userland? If the system has the possibility to run 64-bit binaries then it is not a 32-bit userland. Think nfs mounts. Think cdroms. And since this can change dynamically a system can run 64-bit binaries in the future. If the system is really meant to be a 32-bit userland only then they should run a 32-bit kernel just like classic 32-bit systems. There is no need to run a 64-bit kernel on an amd64/em64t processor. I think at the point that the user has chosen to install the amd64 kernel (such as I have done) they have now moved into multiarch and the system is no longer a pure x86 userland. That was after all the whole point of installing the 64-bit kernel. Users can use a 32-bit kernel if they don't want that. I think someone may have thought that they required a 64-bit kernel on am amd64/em64t processor but that is not true. If they are only running 32-bit applications and want things to be simple and in the well travelled and well tested paths then I would recommend installing a 32-bit kernel. The 64-bit kernel works well but the standards such as FHS address multiarch only poorly and so things are going to be unsettled for the next few years while problems are hashed out. The problem of multiarch is a little confusing. Bob _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
