builds_dont_target_k6

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: Re: rpm and AMD K6
From: jfm2@club-internet.fr
Date: Sun, 27 Aug 2000 11:33:59 +0200 (CEST)

I built an rpm from source. As I'm building on and for an AMD K6, I said, 
> "--target=k6."
> 
> I duly created /u02/summer/redhat/RPMSi586-pc-linux-gnu/k6/fetchmail-5.5.1-1.k6
> rpm, but find I can't install it:
> 
> [root@dugite /root]# rpm --upgrade  /u02/summer/redhat/RPMSi586-pc-linux-gnu/k6
> /fetchmail-5.5
> 1-1.k6.rpm
> package fetchmail-5.5.1-1 is for a different architecture
> 
> unless I specify --ignorearch
> 
> What must I do to avoid having to specify this option each time?
> 
> 

Unless the package has special assembler instructions like Mesa you
shouldn't.  In a K6/2 (notice this is not a plain K6) code compiled
for K6 is slower that code you let alone ie compiled for 386.

===
Subject: Re: rpm and AMD K6 
From: John Summerfield <summer@OS2.ami.com.au>
Date: Mon, 28 Aug 2000 07:27:59 +0800

I built an rpm from source. As I'm building on and for an AMD K6, I said, 
> > "--target=k6."
> > 
> > I duly created /u02/summer/redhat/RPMSi586-pc-linux-gnu/k6/fetchmail-5.5.1-
> 1.k6
> > rpm, but find I can't install it:
> > 
> > [root@dugite /root]# rpm --upgrade  /u02/summer/redhat/RPMSi586-pc-linux-gn
> u/k6
> > /fetchmail-5.5
> > 1-1.k6.rpm
> > package fetchmail-5.5.1-1 is for a different architecture
> > 
> > unless I specify --ignorearch
> > 
> > What must I do to avoid having to specify this option each time?
> > 
> > 
> 
> Unless the package has special assembler instructions like Mesa you
> shouldn't.  In a K6/2 (notice this is not a plain K6) code compiled
> for K6 is slower that code you let alone ie compiled for 386.
> 


Jean
Are you sure about this? I'm using gcc 2.95 which has special options for the 
K6 family.

Checks...
Umm
We're both wrong. I have a fetchmail src.rpm to hand; it's trouble-free and 
doesn't take long to build, so I did this:
rpm --rebuild --target k6 /u03/tobuild/fetchmail-5.5.0-1.src.rpm

and rpm ran gcc thus:
gcc -DHAVE_CONFIG_H  -c  -I. -I.  -O2 socket.c

so it's compiling for i386


All I get is an rpm I can't install;-((
Wrote: /u02/summer/redhat/RPMSi686-pc-linux-gnu/k6/fetchmail-5.5.0-1.k6.rpm

Now..
It doesn't make sense to me that gcc should produce worse code for the K6 (it 
IS a K6-II) if I tell it to compile for one than if I don't, but I will 
compile something and check it out iff
1)  I can coax rpm to build properly for the K6
2)  I can coax rpm to install for it.

Any clues about how I do it?

===













===
Subject: Re: rpm and AMD K6
From: "Mike A. Harris" <mharris@meteng.on.ca>
Date: Sun, 27 Aug 2000 10:22:18 -0400 (EDT)

On Sun, 27 Aug 2000, John Summerfield wrote:

>I built an rpm from source. As I'm building on and for an AMD K6, I said, 
>"--target=k6."
>
>I duly created /u02/summer/redhat/RPMSi586-pc-linux-gnu/k6/fetchmail-5.5.1-1.k6
>.rpm, but find I can't install it:
>
>[root@dugite /root]# rpm --upgrade  /u02/summer/redhat/RPMSi586-pc-linux-gnu/k6
>/fetchmail-5.5
>.1-1.k6.rpm
>package fetchmail-5.5.1-1 is for a different architecture
>
>unless I specify --ignorearch
>
>What must I do to avoid having to specify this option each time?

Edit /usr/lib/rpm/rpmrc... it is more or less self explanatory.

This begs a question...

Why is rpmrc in /usr/lib/rpm/?  Should it not make more sense in
/var/lib/rpm/?  I mean this is a configuration file, and it is in
/usr which is sometimes mounted read-only.  Not a very good idea
IMHO.  It would make _much_ more sense under /var/...

If your /usr is read only, move the file to /var/lib/rpm and make
a symlink in /usr/lib/rpm..

TTYL

===

Subject: Re: rpm and AMD K6
From: Matt Wilson <msw@redhat.com>
Date: Sun, 27 Aug 2000 19:31:47 -0400

NO NO NO!  /etc/rpm/macros and /etc/rpm/rpmrc are for local changes!

===

Subject: Re: rpm and AMD K6
From: Chris Abbey <cabbey@bresnanlink.net>
Date: Sun, 27 Aug 2000 20:55:20 -0500

At 19:31 8/27/00 -0400, Matt wrote:
>NO NO NO!  /etc/rpm/macros and /etc/rpm/rpmrc are for local changes!

well, I don't know about Mike, Jean or John... but I for one am not
psychic... perhaps a nice little message at the top of /usr/lib/rpm/
copies of the files along the lines of:

# This is a static RPM configuration file, local user edits should
#  be done in the /etc/rpm/ files not here.

would be appropriate? -=Chris

===

Subject: Re: rpm and AMD K6
From: Matt Wilson <msw@redhat.com>
Date: Mon, 28 Aug 2000 03:18:11 -0400

On Mon, Aug 28, 2000 at 01:09:25AM -0400, Mike A. Harris wrote:
> 
> Sorry...  I couldn't find that in the nonexistant RPM manual.  
> ;o)  Actually.. it probably is in Maximum RPM even though it's
> outdated, so I'll shut up now.  ;o)

Maximum RPM, index:  "rpmrc, locations of:  368"

On page 368:

Next, we have /etc/rpmrc.

B 2.2  /etc/rpmrc

The file /etc/rpmrc, unline /usr/lib/rpmrc, is fair game for
modifications and additions.  In face, /etc/rpmrc isn't created by
default, so its contents are entirely up to you.  It's the perfect
place to keep rpmrc entries of a system-wide or global nature.

...

Cheers,

===

Subject: Re: rpm and AMD K6
From: jfm2@club-internet.fr
Date: Mon, 28 Aug 2000 22:29:14 +0200 (CEST)

Unless the package has special assembler instructions like Mesa you
> > shouldn't.  In a K6/2 (notice this is not a plain K6) code compiled
> > for K6 is slower that code you let alone ie compiled for 386.
> > 
> 
> 
> Jean
> Are you sure about this? I'm using gcc 2.95 which has special options for the 
> K6 family.
> 

In fact what I told was valid for gcc 2.96.  For gcc 2.95 at O2
optimization level and using the Byte benchmarks the code generated
with arch=k6 (optimize for k6, compiler is free to pick k6 specific
instructions) is: 1% slower for memory-intensive tests, 1.5% faster
for integer tests, 2% slower at floating point tests respective to
code targetted at 386.  Tests were run on a K6/2 450.  In othzer words
either gcc 2.95 does not amke a good job at optimizing specifically
for K6 or the K6/2 is internally different enough from the K6 to make
K6 optimizations ineffective.

===

Subject: Re: rpm and AMD K6 
From: John Summerfield <summer@OS2.ami.com.au>
Date: Tue, 29 Aug 2000 07:53:13 +0800

On Mon, Aug 28, 2000 at 01:09:25AM -0400, Mike A. Harris wrote:
> > 
> > Sorry...  I couldn't find that in the nonexistant RPM manual.  
> > ;o)  Actually.. it probably is in Maximum RPM even though it's
> > outdated, so I'll shut up now.  ;o)
> 
> Maximum RPM, index:  "rpmrc, locations of:  368"
> 
> On page 368:
> 
> Next, we have /etc/rpmrc.
> 
> B 2.2  /etc/rpmrc
> 
> The file /etc/rpmrc, unline /usr/lib/rpmrc, is fair game for
> modifications and additions.  In face, /etc/rpmrc isn't created by
> default, so its contents are entirely up to you.  It's the perfect
> place to keep rpmrc entries of a system-wide or global nature.
> 

well, yes, but M RPM applies to rpm 2.5, doesn't it?

rpm 3.0 rearranged things to GKW, and knowing some of the information in that 
book is obsolete I don't know what to trust.

I'm not psychic either.

===

Subject: Re: rpm and AMD K6 
From: John Summerfield <summer@OS2.ami.com.au>
Date: Tue, 29 Aug 2000 07:47:20 +0800

Edit /usr/lib/rpm/rpmrc... it is more or less self explanatory.

That's error-prone; it gets replaced whenever I upgrade rpm, and I seem to be 
forced to do that altogether TOO often lately.

> 
> This begs a question...
> 
> Why is rpmrc in /usr/lib/rpm/?  Should it not make more sense in
> /var/lib/rpm/?  I mean this is a configuration file, and it is in
> /usr which is sometimes mounted read-only.  Not a very good idea
> IMHO.  It would make _much_ more sense under /var/...

ro if fine for that configuration file IFF users don't ever need to change it.

User-changeable configuration files surely belong in /etc

The rpm database belongs under /var (it's "state" information).

===

Subject: Re: rpm and AMD K6 
From: "Mike A. Harris" <mharris@meteng.on.ca>
Date: Tue, 29 Aug 2000 00:50:16 -0400 (EDT)

On Tue, 29 Aug 2000, John Summerfield wrote:

>Date: Tue, 29 Aug 2000 07:47:20 +0800
>From: John Summerfield <summer@OS2.ami.com.au>
>To: redhat-devel-list@redhat.com
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: rpm and AMD K6 
>
>> 
>> Edit /usr/lib/rpm/rpmrc... it is more or less self explanatory.
>
>That's error-prone; it gets replaced whenever I upgrade rpm, and I seem to be 
>forced to do that altogether TOO often lately.

When I edit files like that, I then do a "chattr +i filename" and
it solves that problem.  ;o)  Perhaps a bad thing to do, but if
it breaks, I get to keep both pieces.  ;o)


===

Subject: Re: rpm and AMD K6
From: jfm2@club-internet.fr
Date: Tue, 29 Aug 2000 08:59:19 +0200 (CEST)

On Tue, 29 Aug 2000, John Summerfield wrote:

> >> Edit /usr/lib/rpm/rpmrc... it is more or less self explanatory.
> >
> >That's error-prone; it gets replaced whenever I upgrade rpm, and I seem to be 
> >forced to do that altogether TOO often lately.
> 
> When I edit files like that, I then do a "chattr +i filename" and
> it solves that problem.  ;o)  Perhaps a bad thing to do, but if
> it breaks, I get to keep both pieces.  ;o)
> 
> 

Emacs automatically saves old files.  It can even put them under
version control if it sees a CVS or RCS directory.  This way you don't
lose the original file in case you save repeatedly.  And it makes a
nicer info reader. ;-)

===

Subject: Re: rpm and AMD K6 
From: John Summerfield <summer@OS2.ami.com.au>
Date: Tue, 29 Aug 2000 15:23:33 +0800

Edit /usr/lib/rpm/rpmrc... it is more or less self explanatory.
> > >
> > >That's error-prone; it gets replaced whenever I upgrade rpm, and I seem to
>  be 
> > >forced to do that altogether TOO often lately.
> > 
> > When I edit files like that, I then do a "chattr +i filename" and
> > it solves that problem.  ;o)  Perhaps a bad thing to do, but if
> > it breaks, I get to keep both pieces.  ;o)
> > 
> > 
> 
> Emacs automatically saves old files.  It can even put them under
> version control if it sees a CVS or RCS directory.  This way you don't
> lose the original file in case you save repeatedly.  And it makes a

Of course, neither of these techniques solves the problem of rpm clobbering 
the most-desired version of the file

However, as rpm apparently reads some files from /etc (if they exist), that 
seems a sensible way to go. It's easy to undo too;-)

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu