curses, python20/152, RH70/62, postgresql problems

Bill Anderson anderson at boi.hp.com
Fri Jan 26 08:48:38 EST 2001


D-Man wrote:
> 
> On Fri, Jan 19, 2001 at 03:18:16AM +0000, A.M. Kuchling wrote:
> | Let's tackle these one by one.
> | On Thu, 18 Jan 2001 15:44:49 GMT, dubal at my-deja.com <dubal at my-deja.com> wrote:
> | >We then tried to compile Py20 source on RH7. It
> | >gives some LONG_BIT error and stops.
> |
> | This is not a GCC problem; it is a glibc problem.  Red Hat has
> | released an updated RPM for glibc, so installing it should let you
> | compile Python 2.0 without difficulty.  Trying to use kgcc wouldn't
> | help, because it's not the compiler's fault.
> |
> 
> Could you provide some more details on the glibc problem?  I used to
> have RH7 and didn't find anything obviously wrong in the headers, so I
> assumed it was the compiler that wasn't doing the comparison
> correctly.  I solved the problem by manually editing the header (
> <bits/xopen_lim.h> ).  I have since upgraded to Debian, but am still
> curious.
> 
> Basically, for RH7 users : you can't use any rpms that people provide.

Basically, you are wrong.

I have many rpms I've installed on this (and several other RH7) that
were built on non-RH7 Machines. In fact I have many that I built on
RH6.[0-2] installed here on this very 7.0 box. (Part of this is due to
the 6-way XEON box still running 6.2 ... for now)

> RH used an incompatible compiler, so you must compile stuff yourself.
> (Or find RH7 specific rpms)  Also note that stuff compiled with newer
> versions of gcc (3.0 when it is released) for newer dists (I assume RH
> will use 3.0 when it is released) won't work on RH7 either.  Rpms made


You mean like how stuff compiled for RH6.x won't run on 5.x because
there was a glibc change there too? That is a result of the change in
glibc, and not RH. When any distribution (ewven one you build from
scratch) moves to a newer major version of glibc, then programs compiled
against that glibc will not work on earlier versions. Now, there is the
option of installing backwards compatible libraries to compile against,
so you _can_ compile apps on a newer distribution aimed at an older one,
it just takes extra effort (as it should, really).

Of course, you could upgrade the 6.x to have the newer glibc (and all
the toys that go with it), and it will work fine. In fact, I did this
with an alpha machine. That machine started with 5.0, and has been
manually upgraded via rpms to 7.0, no use of the RH installer to do it
(yes it was a bit time consuming ;). Works fine. That's one of the neat
things about rpms; it isn't that difficult to upgrade what you need. :)


> for RH7 or RH6 (or anything older) won't work on the a dist with the
> new compiler.

Not neccesarily, but possibly, and then again, it may very well be app
(code) specific.

The big issue with RPMS made on 7.0 is that they use a newer version of
RPM that is incompatible with the stock RH6.x rpm version. Of course, if
that were the only issue, you could just upgrade the rpm version.

-- 
Bill Anderson               Linux Specialist
Modular Network Storage     R&D           
Random Quote:
    Portable: survives system reboot.



More information about the Python-list mailing list