Re: checking tool status on RedHat systems 7.1

[Marcus G. Daniels]

>>>>> "PJ" == pauljohn  <address@hidden> writes:

PJ> 1. hdf5.  Is 1.4.2 good for you?  Am I safe to start building
PJ> swarm rpms against it?

Well, I use it all the time.  Like, gigabytes of simulation traces..
But this is on Solaris, not Redhat 7.1.

PJ> 2. jikes.  Are you using the one RedHat distributes now?

Jikes 1.13 is what I have on Redhat 7.1.  Works ok for me.
[Incidentally, it isn't possible to build Swarm using the KJC compiler
in Kaffe -- it doesn't handle cross-package compilation.  (I know you
know that Paul, but for the sake of other people..]

For people building Swarm from source, I'd strongly suggest using
Jikes.  It's much faster and it's a known quantity. 

PJ> 1. The RedHat gcc3.spec file requires a newer binutils than in
PJ> RH7.1:

PJ> I can't upgrade binutils without upgrading glibc (or so rpm
PJ> tells me),

PJ> BuildRequires: binutils >= 2.11.90.0.8-3
PJ> gcc-3.0.1 builds with the binutils I have
PJ> binutils-2.10.91.0.2-3

Huh?  This seems to imply you upgraded your glibc.  From my
perspective, I would say it is generally a mistake to relax
constraints for the sake of making it convenient for users of your
RPMs.  The binutils requirement for GCC is real.  Either introducing
parallel versions of low level development tools to avoid other
upgrades or, worse, creating a situation where very obscure bugs in
code generation occur is only going to make more work for you and
create hopeless debugging situations for naive users.  (Aren't there
several outstanding now?)  I think the best thing is to have very tight
constraints even if it means a fair amount of mechanical work for users.

PJ> 2.  Why does RedHat not distribute cpp with gcc3? Until now, there
PJ> has always been a cpp package.  I GUESS they expect me to use cpp
PJ> from gcc-2.96 and not bother with cpp3? HOwever, their gcc3
PJ> package does have file cpp0 in there. What's up with that?

I suppose it has to do with the fact that cpp is now integrated with
the compiler binary itself.  Hopefully, soon, GCC 3 will become the
standard compiler everywhere.  The current situation with Redhat's custom
compiler version and complex integration rules (e.g. libgcj3 depending on 
some earlier verison) are extremely annoying to me.  

PJ> 3. In their SPEC file, there is a requirement I can't understand
PJ> for libgcj.  Why would the libgcj3 package require the previous
PJ> installation of libgcj?

Don't know..  It may just confuse matters to use their spec files for
guidance.  Sigh, things were so much simpler in the old days..

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.