This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING^2: [PATCH] Correct _{POSIX_V7|_POSIX_V6|XBS5}_ILP32_OFFBIGfor x32


I am no less dubious about this than I was several months ago.

I don't think POSIX ever contemplated the situation we now have, wherein
there are two disjoint compilation environments that qualify as ILP32_OFFBIG.

I'm not convinced there is ever going to be one right answer here.

On a system installation that supports -mx32 but does not have a
full environment for -m32, then -mx32 is the right answer.  

On a system installation that fully supports both -m32 and -mx32
builds, there are different ways to conclude which is preferable.
It seems entirely reasonable to me that for a system Foo version 17
for x86-64 that supports only -m64 and -m32, the system builder
might come out with system Foo version 18 for x86-64 where not only
is -mx32 available, but most or all of the user utilities are built
with -mx32.  If someone was using getconf _POSIX_V7_ILP32_OFFBIG on
version 17, they got -m32 -D_FILE_OFFSET_BITS=64 and built binaries
compatible with system Foo version 17 for i686.  Now they upgrade to
system Foo version 18 for x86-64, and they might reasonably expect
that they can continue to use getconf _POSIX_V7_ILP32_OFFBIG to
build binaries compatible with system Foo version 18 for i686.

It should be up to the system builder to decide whether getconf
directs users to use -m32 or -mx32.

So I tend to think this should be controlled by a configure option,
and the default should not be changed by building libc as x32.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]