Thread: Re: [COMMITTERS] pgsql/src/backend/utils/adt (cash.c)

> Modify locale code to defend against possibility that it was compiled
> with an -fsigned-char/-funsigned-char setting opposite to that of libc,
> thus breaking the convention that 'undefined' values returned by
> localeconv() are represented by CHAR_MAX.  It is sheer stupidity that
> gcc even has such a switch --- it's just as bad as the structure-packing
> control switches offered by the more brain-dead PC compilers --- and
> as for the behavior of Linux distribution vendors who set RPM_OPT_FLAGS
> differently from the way they built libc, well, words fail me...

Which distros would these be? I know that Mandrake chooses some mutually
exclusive flags (-On and -fast-math) but am not sure which other ones
are inconsistant...
                     - Thomas

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> as for the behavior of Linux distribution vendors who set RPM_OPT_FLAGS
>> differently from the way they built libc, well, words fail me...

> Which distros would these be? I know that Mandrake chooses some mutually
> exclusive flags (-On and -fast-math) but am not sure which other ones
> are inconsistant...

The particular problem I was having was with LinuxPPC 2000.  gcc's
default behavior on PPC is -funsigned-char, and that seems to be the
way that libc was built in that distro.  But /usr/lib/rpm/rpmrc sets
RPM_OPT_FLAGS to "-fsigned-char -O2".  (The -O2 wreaks havoc with
Postgres too, pre-fmgr-rewrite, but at least we knew about that effect.)

On closer examination, I think the blame lies with the RPM people and
not with LinuxPPC per se, because /usr/lib/rpm/rpmrc comes straight
from the RPM distro.  Seems to me that libc *should* be built with
the default char-signedness for the platform, because otherwise programs
built outside the RPM environment will be broken.  When RPM attempts to
force a non-default signedness for programs built in the RPM
environment, the only possible consequence is that someone or other gets
broken --- either RPM-based programs or non-RPM-based-programs, take
your pick.  Ergo, it's RPM that's broken.

That same file has a bunch of apparently non-default compiler options
for other platforms besides PPC (for your amusement, I attach the
relevant lines from rpm-3.0.5 below).  I wonder how many of those are
equally misguided...
        regards, tom lane

# Values for RPM_OPT_FLAGS for various platforms

optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: i486 -O2 -march=i486
optflags: i586 -O2 -march=i586
optflags: i686 -O2 -march=i686
optflags: athlon -O2 -march=athlon
optflags: ia64 -O2

# XXX Please note that -mieee has been added in rpm-3.0.5.
optflags: alpha -O2 -mieee

optflags: sparc -O2 -m32 -mtune=ultrasparc
optflags: sparcv9 -O2 -m32 -mcpu=ultrasparc
optflags: sparc64 -O2 -m64 -mcpu=ultrasparc
optflags: m68k -O2 -fomit-frame-pointer
optflags: ppc -O2 -fsigned-char
optflags: parisc -O2 -mpa-risc-1-0
optflags: hppa1.0 -O2 -mpa-risc-1-0
optflags: hppa1.1 -O2 -mpa-risc-1-0
optflags: hppa1.2 -O2 -mpa-risc-1-0
optflags: hppa2.0 -O2 -mpa-risc-1-0
optflags: mipseb -O2
optflags: mipsel -O2
optflags: armv4b -O2 -fsigned-char -fomit-frame-pointer
optflags: armv4l -O2 -fsigned-char -fomit-frame-pointer
optflags: atarist -O2 -fomit-frame-pointer
optflags: atariste -O2 -fomit-frame-pointer
optflags: ataritt -O2 -fomit-frame-pointer
optflags: falcon -O2 -fomit-frame-pointer
optflags: atariclone -O2 -fomit-frame-pointer
optflags: milan -O2 -fomit-frame-pointer
optflags: hades -O2 -fomit-frame-pointer

Tom Lane wrote:
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> >> as for the behavior of Linux distribution vendors who set RPM_OPT_FLAGS
> >> differently from the way they built libc, well, words fail me...
> > Which distros would these be? I know that Mandrake chooses some mutually
> > exclusive flags (-On and -fast-math) but am not sure which other ones
> > are inconsistant...
> The particular problem I was having was with LinuxPPC 2000.  gcc's
> default behavior on PPC is -funsigned-char, and that seems to be the
> way that libc was built in that distro.  But /usr/lib/rpm/rpmrc sets
> RPM_OPT_FLAGS to "-fsigned-char -O2".  (The -O2 wreaks havoc with
> Postgres too, pre-fmgr-rewrite, but at least we knew about that effect.)
> On closer examination, I think the blame lies with the RPM people and
> not with LinuxPPC per se, because /usr/lib/rpm/rpmrc comes straight
> from the RPM distro.  Seems to me that libc *should* be built with

It's more of a combination -- if the LinuxPPC people are overriding the
default RPM_OPT_FLAGS with their own stuff for libc, that's not an RPM
problem.

OTOH, RPM_OPT_FLAGS for that compiler on PPC should not have -O2, if -O2
causes other packages on that platform to barf.  Of course, IIRC, we
have historically had problems with -O2 on some architectures pre-fmgr
rewrite.  So the problem lies with all three: it's our problem -O2
causes problems; it's LinuxPPC's problem that libc is compiled with the
non-RPM_OPT_FLAGS char signage; and it's RPM's problem that
RPM_OPT_FLAGS has a non-default char signage for PPC.  So, the short
term fix is to patch our spec file (which we've done for PPC).

The person to inform of generic RPM issues is Jeff Johnson
(jbj@redhat.com), aka Mr. Rpm.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11