This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: Fix __WORDSIZE for ia64.
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: "H. J. Lu" <hjl at lucon dot org>, GNU C Library <libc-alpha at sources dot redhat dot com>
- Date: Fri, 1 Aug 2003 10:37:48 +0200
- Subject: Re: PATCH: Fix __WORDSIZE for ia64.
- References: <20030801024901.GA22839@lucon.org> <200308010813.h718DXR01239@magilla.sf.frob.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Aug 01, 2003 at 01:13:33AM -0700, Roland McGrath wrote:
> > With this change, the only loss is we can no longer access the old utmp
> > file. I think it is the price we should pay to fix the problem.
> I am inclined to agree with this conclusion (the same one made on other
> 64/32 platforms). But it's not a change you just slip in without comment,
> discussion with users and system maintainers, and approval from the
> architecture's canonical maintainer.
There are many programs which access utmp directly and use struct utmp
or struct lastlog for that (instead of using the libc acess functions).
Defining __WORDSIZE_COMPAT32 macro on ia64 means you simply abandon
compatibility with any ia64 programs which ever use utmp/wtmp/lastlog,
whether through accessor functions or poking at the files directly.
Given how slowly IA-32 programs run on IA-64, I think it is certainly
not worth breaking compatibility for the native programs to gain
compatibility with the emulated ones.
If we can get rid of all the programs poking directly, then we certainly
can through symbol version do anything with struct utmp (and translate the
structures from one format to the other).
But best would be of course to use 64-bit format on disk and translate it
to 32-bit programs.
I think it is even questionable whether to define __WORDSIZE 32 in IA-64
headers if __ia64__ is not defined. IA-64 does not use */lib64 and its
compiler is not bi-architecture either. To build IA-32 binaries on IA-64
box you have to pass -L/usr/i386-something-linux/lib or where the libraries
live to the cross-compiler anyway, at which point I don't see why
passing -I/usr/i386-something-linux/include cannot be done too
(well, the cross-compiler can be even configured so that it does that