[gentoo-amd64] ~amd64 vs. ~x86

[gentoo-amd64] ~amd64 vs. ~x86

[Mark Knecht]

On another list, music based, I was told by someone that using both
~x86 and ~AMD64 on the same system is incorrect by design. I have no
reason to not believe him but I seem to have missed this point when I
was building this system.

Can someone clarify if this is the case? If so, what is the
recommended action for me to take at this point?

Thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Olivier Crete]

On Mon, 2005-28-11 at 16:23 -0800, Mark Knecht wrote:
> On another list, music based, I was told by someone that using both
> ~x86 and ~AMD64 on the same system is incorrect by design. I have no
> reason to not believe him but I seem to have missed this point when I
> was building this system.
> 
> Can someone clarify if this is the case? If so, what is the
> recommended action for me to take at this point?

As a general rule, you should NEVER put x86 or ~x86 in your
ACCEPT_KEYWORDS or package.keywords on an amd64 system using an amd64
profile. 


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Harm Geerts]

On Tuesday 29 November 2005 01:23, Mark Knecht wrote:
> On another list, music based, I was told by someone that using both
> ~x86 and ~AMD64 on the same system is incorrect by design. I have no
> reason to not believe him but I seem to have missed this point when I
> was building this system.
>
> Can someone clarify if this is the case? If so, what is the
> recommended action for me to take at this point?

It depends on the profile you are currently using.

# ls -l /etc/make.profile
lrwxrwxrwx  1 root root 50 mei 11  2005 /etc/make.profile 
-> ../usr/portage/profiles/default-linux/amd64/2005.0

As you can see my system is using the amd64 profile version 2005.0
That gives ACCEPT_KEYWORDS a default value of "amd64"
If I want to run packages marked unstable for amd64 I would change the 
ACCEPT_KEYWORDS value to "~amd64" in /etc/make.conf

ACCEPT_KEYWORDS decides which package versions portage should use when merging 
something.
Each ebuild has a KEYWORDS variable, it lists all the arches that can use that 
version of a package.

So by setting ACCEPT_KEYWORDS="~x86" on a amd64 profile you might install 
packages that are only tested for ~x86. This can lead to serious problems 
with packages that are broken on amd64 (and therefore not keyworded as amd64)

You should set ACCEPT_KEYWORDS to the correct value for your profile.
Then run the following to make sure all installed packages are keyworded for 
your profile.

# emerge -DNup world
# revdep-rebuild -p
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Mark Knecht]

On 11/28/05, Harm Geerts <harmgeerts@home.nl> wrote:
> On Tuesday 29 November 2005 01:23, Mark Knecht wrote:
> > On another list, music based, I was told by someone that using both
> > ~x86 and ~AMD64 on the same system is incorrect by design. I have no
> > reason to not believe him but I seem to have missed this point when I
> > was building this system.
> >
> > Can someone clarify if this is the case? If so, what is the
> > recommended action for me to take at this point?
>
> It depends on the profile you are currently using.
>
> # ls -l /etc/make.profile
> lrwxrwxrwx  1 root root 50 mei 11  2005 /etc/make.profile
> -> ../usr/portage/profiles/default-linux/amd64/2005.0
>
> As you can see my system is using the amd64 profile version 2005.0
> That gives ACCEPT_KEYWORDS a default value of "amd64"
> If I want to run packages marked unstable for amd64 I would change the
> ACCEPT_KEYWORDS value to "~amd64" in /etc/make.conf
>
> ACCEPT_KEYWORDS decides which package versions portage should use when merging
> something.
> Each ebuild has a KEYWORDS variable, it lists all the arches that can use that
> version of a package.
>
> So by setting ACCEPT_KEYWORDS="~x86" on a amd64 profile you might install
> packages that are only tested for ~x86. This can lead to serious problems
> with packages that are broken on amd64 (and therefore not keyworded as amd64)
>
> You should set ACCEPT_KEYWORDS to the correct value for your profile.
> Then run the following to make sure all installed packages are keyworded for
> your profile.
>
> # emerge -DNup world
> # revdep-rebuild -p
> --
> gentoo-amd64@gentoo.org mailing list

Thanks Harm and thanks to Oliver also.

OK, my system is similar to yours:

mark@lightning ~ $ ls -l /etc/make.profile
lrwxrwxrwx  1 root root 50 Aug 30 09:50 /etc/make.profile ->
../usr/portage/profiles/default-linux/amd64/2005.1


However, to get the apps running that I wanted to run I've ended up
with a messy set of keywords:

mark@lightning ~ $ cat /etc/portage/package.keywords
gnome-base/gnome-light amd64
media-video/helixplayer amd64
media-libs/win32codecs amd64
net-irc/xchat-gnome amd64
x11-base/x11-drm amd64

app-admin/eselect-opengl ~amd64
app-admin/eselect ~amd64
sys-apps/sdparm ~amd64
sys-kernel/gentoo-sources ~amd64
x11-themes/fvwm-crystal ~amd64
x11-misc/trayer ~amd64
x11-wm/fvwm ~amd64
x11-misc/habak ~amd64
media-libs/libiec61883 ~amd64
sys-libs/libraw1394 ~amd64
sci-electronics/iverilog ~amd64
media-plugins/mythmusic ~amd64

net-www/mplayerplug-in ~amd64

media-sound/om ~amd64
media-libs/liblo ~amd64
app-emulation/emul-linux-x86-xlibs ~amd64
#media-video/ati-drivers ~amd64
#media-video/ati-drivers-extra ~amd64
x11-base/xorg-x11 ~amd64

app-cdr/k3b ~x86
app-emulation/wine ~x86
media-libs/liblrdf ~x86
media-sound/snd ~x86
media-video/xine-ui ~x86
x11-libs/fltk ~x86

sys-fs/hfsplusutils x86
sys-fs/mac-fdisk ~x86

media-sound/alsa-headers ~amd64
media-plugins/alsa-jack ~amd64
media-libs/alsa-lib ~amd64
media-sound/alsa-oss ~x86
media-sound/alsa-tools ~x86
media-sound/alsa-utils ~amd64
media-sound/alsa-jack ~amd64
media-sound/jack-rack ~x86

x11-libs/fltk ~amd64
mark@lightning ~ $

A questions though. Just because an app is not tested on AMD64, and
hence not keyworded with amd64 or ~amd64, doesn't mean it has a
problem, does it? It just means it's not tested, right? Or am I
incorrect in that?

Thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Nuitari]

> A questions though. Just because an app is not tested on AMD64, and
> hence not keyworded with amd64 or ~amd64, doesn't mean it has a
> problem, does it? It just means it's not tested, right? Or am I
> incorrect in that?

As I understand it, if it doesn't have -amd64 then it means it hasn't been 
tested.

Some apps have a -* in the keywords, that means to mask it everywhere 
except the others arch. If it is ~x86 then it _might_ work with amd64.


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

Mark Knecht <markknecht@gmail.com> writes:
> app-cdr/k3b ~x86

I would at least write this sort of thing as "=app-cdr/k3b-1.2.3-r17
~x86" or something like that, or else, if I wanted to be proper in
every way, I'd make a portage overlay. Either way, you won't get
informed of new versions unless they are ~amd64, but that's probably
close to what you want with an 'untested' program.

> app-emulation/wine ~x86

Does that actually work? Why, yes, I see it is keyworded for ~amd64.
In any case, what you have just tells the system to use the latest x86
'unstable' version, but it's going to get built for amd64
regardless. You can change the ~x86 to ~amd64, and probably you can do
the same for a lot of the other packages.


-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Barijo.SXVARCO@chemoelectric.org
   'And now we're going to go try to comfort people in that
 part of the world.' -- Bush, referring to the southeastern U.S.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Jonathan Schaeffer]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

Mark Knecht wrote:

>
>app-cdr/k3b ~x86
>
>  
>
Why this ? According to http://gentoo-portage.com/app-cdr/k3b ~amd64 and 
~x86 are pointing on the same version.

Jonathan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Alex Bennee]

On Mon, 2005-11-28 at 19:52 -0800, Mark Knecht wrote:

> A questions though. Just because an app is not tested on AMD64, and
> hence not keyworded with amd64 or ~amd64, doesn't mean it has a
> problem, does it? It just means it's not tested, right? Or am I
> incorrect in that?

Sure, but you it depends if you want to make all x86 (but not amd64 or
~amd64) apps available. My personal preference is to clone the ebuilds
of stuff I want to try that hasn't got an amd keyword of one sort or
another into my overlay directory and then build them. This means my
systems is:

* mainly stable amd64 packages
* with a selection of ~amd64 packages (via package.keywords)
* with a few cloned/overlayed x86 only builds manually editied to be
~amd64

Hopefully this stops you whole system being pulled into an unstable
state.

--
Alex, homepage: http://www.bennee.com/~alex/
If I am elected, the concrete barriers around the WHITE HOUSE will be
replaced by tasteful foam replicas of ANN MARGARET!

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Mark Knecht]

On 11/29/05, Jonathan Schaeffer <joschaeffer@gmail.com> wrote:
> Mark Knecht wrote:
>
> >
> >app-cdr/k3b ~x86
> >
> >
> >
> Why this ? According to http://gentoo-portage.com/app-cdr/k3b ~amd64 and
> ~x86 are pointing on the same version.
>
> Jonathan

At the time I first built k3b on the system it seemed that ~amd64
didn't build. I tried ~x86 not knowing better and it did. I continued
to use k3b that way successfully.

Subsequent to this thread I changed it to ~amd64 last evening and it
built fine. I have not used it yet, but as you say it's the same
version so it should work.

thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Mark Knecht]

On 11/29/05, Alex Bennee <alex@bennee.com> wrote:
> On Mon, 2005-11-28 at 19:52 -0800, Mark Knecht wrote:
>
> > A questions though. Just because an app is not tested on AMD64, and
> > hence not keyworded with amd64 or ~amd64, doesn't mean it has a
> > problem, does it? It just means it's not tested, right? Or am I
> > incorrect in that?
>
> Sure, but you it depends if you want to make all x86 (but not amd64 or
> ~amd64) apps available. My personal preference is to clone the ebuilds
> of stuff I want to try that hasn't got an amd keyword of one sort or
> another into my overlay directory and then build them. This means my
> systems is:
>
> * mainly stable amd64 packages
> * with a selection of ~amd64 packages (via package.keywords)
> * with a few cloned/overlayed x86 only builds manually editied to be
> ~amd64
>
> Hopefully this stops you whole system being pulled into an unstable
> state.

Yes, I hope so. Since I never build with ACCEPT_KEYWORDS="~x86" but
rather put all keywords in package.keywords, I've rebuilt almost all
the ~x86 applications with ~amd64. I have not done the --emptytree
rebuild yet and may not for the next week or two just to see how
things go.

Thanks for the strategies.

cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Tuesday 29 November 2005 12:39, Mark Knecht wrote:
> Yes, I hope so. Since I never build with ACCEPT_KEYWORDS="~x86" but
> rather put all keywords in package.keywords, I've rebuilt almost all
> the ~x86 applications with ~amd64. I have not done the --emptytree
> rebuild yet and may not for the next week or two just to see how
> things go.

Rebuilding is not necessary. What would probably be a better strategy than 
an --emptytree is the following:

find /var/db/pkg -mindepth 3 -maxdepth 3 -name "*.ebuild" -exec egrep -H \ 
"^KEYWORDS" {} \; |egrep -v "[^-]amd64"

This will find you all ebuilds that do not have any amd64 keywords. You 
should try to merge newer versions to see whether the new version is 
supported. If not, they are likely not to work. If the outputted keywords 
include -amd64 they WILL not work. If they do work and are not marked for 
amd64 then you might consider to report them.

Paul

ps. Please remember, keywords do not change packages or the build process. 
They are only used to determine whether the package should be provided on 
that architecture/testing level.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] ~amd64 vs. ~x86

[Tres Melton]

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

On Mon, 2005-11-28 at 16:23 -0800, Mark Knecht wrote:
> On another list, music based, I was told by someone that using both
> ~x86 and ~AMD64 on the same system is incorrect by design. I have no
> reason to not believe him but I seem to have missed this point when I
> was building this system.
> 
> Can someone clarify if this is the case? If so, what is the
> recommended action for me to take at this point?
> 
> Thanks,
> Mark
> 
And Tester wrote:
> As a general rule, you should NEVER put x86 or ~x86 in your
> ACCEPT_KEYWORDS or package.keywords on an amd64 system using an amd64
> profile. 

I completely agree with the first part of this statement but disagree
with the second.  The system wide ACCEPT_KEYWORDS should never contain
anything x86 on an AMD64 system but I often put them into
package.keywords.  I asked almost this same question on IRC the other
day and I'll paste the contents of that discussion here:

RiverRat Question:  Does the ACCEPT_KEYWORDS value ever get interpretted for anything other than to see if a package can be installed via masking.  In other words, if I add ~x86 to something on my amd64 will that ever make it to compile flags or anything like that?  I've done that for perl/python scripts as I know the interrupter was compiled correctly but I'm leary of adding it to binary files.  It is just for testing and temporary use but is that o
RiverRat k,  or should I always use overlays to prevent system b0rkage?
* iluxa has quit (Remote closed the connection)
chutzpah RiverRat: deltacow and i use ~* * in package.keywords to unmask packages all the time
hparker I always use overlays for testing, portage.keywords for apps I will leave ~ on the system.. Just helps me keep things straight 
RiverRat chutzpah: Cool, so -m32 never makes it into the CFLAGS as a result?  I would be highly annoyed if it did.
hparker s/portage/package
* hparker looks for his coffee cup
chutzpah RiverRat: never has for me... putting append-flags -m32 in any package except for something like grub would be a somewhat dumb thing to do
RiverRat chutzpah: I agree, I just haven't dug through the portage code enough to make a definitive staement about it.  Thanks for the info.
chutzpah RiverRat: no problem
jeeves http://bugs.gentoo.org/show_bug.cgi?id=113822 andrej.filipcic@ijs.si->bug-wranglers@gentoo.org, gfs ebuilds for amd64
RiverRat http://dev.gentoo.org/~g2boojum/portage.html   <-  Good info here for the people like me that are new to this stuff.
dang RiverRat: -m32 would come from ABI, not from ACCEPT_KEYWORDS
RiverRat Thanks, that's what I wanted to know.

So, it should be fine to add them into package.keywords but stay away
from ACCEPT_KEYWORDS with them.  The real problem is programmers using
ints to store pointers and the fact that ints are 32 bits on both
platforms.  Using longs should work on both platforms, or better yet,
declare them as the same kind of pointer that you are using.  :p   There
are other issues between the two processors (alot) but that is the most
common problem.

-- 
Tres Melton
IRC & Gentoo: RiverRat

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: ~amd64 vs. ~x86

[Duncan]

Mark Knecht posted
<5bdc1c8b0511290336j39d95625g3f9d48b80d04827b@mail.gmail.com>, excerpted
below,  on Tue, 29 Nov 2005 03:36:29 -0800:

> At the time I first built k3b on the system it seemed that ~amd64 didn't
> build. I tried ~x86 not knowing better and it did. I continued to use k3b
> that way successfully.
> 
> Subsequent to this thread I changed it to ~amd64 last evening and it built
> fine. I have not used it yet, but as you say it's the same version so it
> should work.

It probably needed something else that you didn't have (that was/is still
marked ~arch for one or the other) the first time you tried it with
~amd64.  By the time you rebuilt it ~x86, you had it or it pulled it in
there.  Now that you have that dependency met, it of course builds on
~amd64 as well.

Note that those running full ~amd64 systems would likely have had the
dependency already merged, thus, it would build for them without the ~x86
intermediate step you took.

....

BTW, one of the reasons x86 and ~x86 are discouraged on an amd64 system (~
or stable) is because in some cases, keyword tests are used to determine
whether a particular portion is built 32-bit or 64-bit.  In particular,
(~)x86 keywording on some packages will cause them to try to build
portions of the package in 32-bit assembly.  Naturally, when the rest of
the package is 64-bit, this will cause serious problems, where it wouldn't
if the package was moved to overlay and (~)amd64 was added, because
that wouldn't trigger the 32-bit specific assembly coding, based
specifically on the (~)x86 keyword.

Most packages don't test on arch keywording specifically, or if they do
it's nothing related to amd64/x86 but rather endianness (as ppc) or other
arch-specific keywording related.  Thus, (~)x86 won't get you into trouble
with /most/ packages.  However, because the ones where it /will/ get you
in trouble tend to be core packages such as gcc, glibc, xorg, etc, and a
problem in /these/ packages could seriously break your system such that
it's difficult to recover without a fresh install, the recommendation is
not to use (~)x86 keywording at all.

For specific packages, therefore, you have two possible solutions.  The
recommended solution is to copy the ebuild to your overlay, add the
(~)amd64 keyword as appropriate, redigest, and try to merge the
rekeyworded copy.  However, if you are careful, and exercise some reason
as to just what you are keywording (~)x86 (don't do it with anything you
consider core, and preferrably take a look at the ebuild to see if it
does anything specific based on the x86 keyword), /then/ you can
reasonably safely add it to package.keywords as (~)x86.  However, this
latter method is /never/ recommended, and if something breaks anyway,
despite your cautions (or lack thereof), as they say, "You get to keep the
pieces!"

So anyway, that's why it seems to work for many individual packages. 
Whether it's worth the risk to you to do it that way, against
recommendations, is of course up to you, since it's your system.  

Now that you have it running with some (~)x86 package keywords,
personally, I'd simply ensure that the various (~)x86 package.keyword
entries were appropriately limited to the specific version you have
currently merged, limiting any future potential breakage, and run with it.
Over time, as new versions come out and are marked (~)amd64, you'll
upgrade to them, and eventually, you'll have a system entirely free of
your current (~)x86 packages.  The idea here is simply why worry about
what's working, and is similar to the approach of a stage-3 plus packages
Gentoo install, where individual site optimizations are only done in the
normal upgrade process.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: ~amd64 vs. ~x86

[Tres Melton]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

On Tue, 2005-11-29 at 07:32 -0700, Duncan wrote:

> BTW, one of the reasons x86 and ~x86 are discouraged on an amd64 system (~
> or stable) is because in some cases, keyword tests are used to determine
> whether a particular portion is built 32-bit or 64-bit.  In particular,
> (~)x86 keywording on some packages will cause them to try to build
> portions of the package in 32-bit assembly.  Naturally, when the rest of
> the package is 64-bit, this will cause serious problems, where it wouldn't
> if the package was moved to overlay and (~)amd64 was added, because
> that wouldn't trigger the 32-bit specific assembly coding, based
> specifically on the (~)x86 keyword.

Duncan, can you give me an example of this behavior?  I forgot which but
a dev said the other day on IRC something like "as far as I know there
is no way to determine the KEYWORD that is allowing the package to be
built from within the ebuild"  I would like to see an example please.


> Most packages don't test on arch keywording specifically, or if they do
> it's nothing related to amd64/x86 but rather endianness (as ppc) or other
> arch-specific keywording related.  Thus, (~)x86 won't get you into trouble
> with /most/ packages.  However, because the ones where it /will/ get you
> in trouble tend to be core packages such as gcc, glibc, xorg, etc, and a
> problem in /these/ packages could seriously break your system such that
> it's difficult to recover without a fresh install, the recommendation is
> not to use (~)x86 keywording at all.

I don't think they test for keywording so much as CTARGET and aim for
that.  How else would the cross compiler work?  If it is not defined or
overloaded then the CHOST value from make.conf will be used won't it?

> For specific packages, therefore, you have two possible solutions.  The
> recommended solution is to copy the ebuild to your overlay, add the
> (~)amd64 keyword as appropriate, redigest, and try to merge the
> rekeyworded copy.  However, if you are careful, and exercise some reason
> as to just what you are keywording (~)x86 (don't do it with anything you
> consider core, and preferrably take a look at the ebuild to see if it
> does anything specific based on the x86 keyword), /then/ you can
> reasonably safely add it to package.keywords as (~)x86.  However, this
> latter method is /never/ recommended, and if something breaks anyway,
> despite your cautions (or lack thereof), as they say, "You get to keep the
> pieces!"

So the issue is do ebuilds use CHOST or KEYWORD to key the build for.  I
don't know enough about portage to say for sure but I thought they all
used CHOST.  If there is one that uses the KEYWORD then link me bud.  :p

Good to see you're still as active as ever on the ML.  I've been
spending too much of my time babysitting in #gentoo on IRC.  :)
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
> 
> 
-- 
Tres Melton
IRC & Gentoo: RiverRat

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Re: ~amd64 vs. ~x86

[Duncan]

Tres Melton posted <1133280913.26819.51.camel@thor.tres.org>, excerpted
below,  on Tue, 29 Nov 2005 09:15:13 -0700:

> So the issue is do ebuilds use CHOST or KEYWORD to key the build for.  I
> don't know enough about portage to say for sure but I thought they all
> used CHOST.  If there is one that uses the KEYWORD then link me bud.  :p

That's possible.  I'm talking about the use tests seen in ebuilds, ie
"if use x86; then" type tests. If you can say definitively that these use
CHOST not keywords, then I'll take your word for it, but I always though
it tested keywords (particularly since amd64 would be x86_64 CHOST,
right? unless the use macro does the conversion from common/gentoo-speak
to chost-speak internally?) but I could certainly be incorrect as it's not
something I've specifically traced.

Both of these from xorg-x11-6.8.99.15-r4.ebuild, host_def_setup section:

Test for amd64 (won't be run if x86)

                # Enable i810 on x86_64 (RH #126687)
                if use amd64; then
                        echo "#define XF86ExtraCardDrivers i810" >> ${HOSTCONF}
                fi

Test for x86 or alpha (won't be run if amd64)

                if use x86 || use alpha; then
                        # build with glide3 support? (build the tdfx_dri.o module)
                        if use 3dfx; then
                                echo "#define HasGlide3 YES" >> ${HOSTCONF}
                        fi
#                       This won't work unless we can disable building the tdfx stuff
#                       entirely :/
#                       use_build 3dfx HasGlide3
                fi

As I said earlier, these sorts of tests tend to be most common in packages
like toolchain (gcc/binutils/etc) and X, but they do occasionally occur
elsewhere, as with x86-optimized assembly in media codec applications,
for instance.  (No specific instances to point out as I've not looked, but
that's the generally given example when pointing out where arch specific
code might be used, even between x86 hardware versions,
386/586/686/mmx/3dnow/sse/sse2/sse3/whatever, tho of course on x86, gentoo
has USE flags for that sort of optimization, where needed.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: ~amd64 vs. ~x86

[Patrick McLean]

Duncan wrote:
> Tres Melton posted <1133280913.26819.51.camel@thor.tres.org>, excerpted
> below,  on Tue, 29 Nov 2005 09:15:13 -0700:
> 
> 
>>So the issue is do ebuilds use CHOST or KEYWORD to key the build for.  I
>>don't know enough about portage to say for sure but I thought they all
>>used CHOST.  If there is one that uses the KEYWORD then link me bud.  :p
> 
> 
> That's possible.  I'm talking about the use tests seen in ebuilds, ie
> "if use x86; then" type tests. If you can say definitively that these use
> CHOST not keywords, then I'll take your word for it, but I always though
> it tested keywords (particularly since amd64 would be x86_64 CHOST,
> right? unless the use macro does the conversion from common/gentoo-speak
> to chost-speak internally?) but I could certainly be incorrect as it's not
> something I've specifically traced.

The tests use the ARCH variable, which is defined in the profile. They 
most certainly do not use the KEYWORDS or attempt to do any magic on the 
CHOST definitions.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: ~amd64 vs. ~x86

[Duncan]

Patrick McLean posted <438CA7BF.9000200@linuxfreak.ca>, excerpted below, 
on Tue, 29 Nov 2005 14:10:55 -0500:

>> That's possible.  I'm talking about the use tests seen in ebuilds, ie
>> "if use x86; then" type tests. If you can say definitively that these
>> use CHOST not keywords, then I'll take your word for it, but I always
>> though it tested keywords (particularly since amd64 would be x86_64
>> CHOST, right? unless the use macro does the conversion from
>> common/gentoo-speak to chost-speak internally?) but I could certainly be
>> incorrect as it's not something I've specifically traced.
> 
> The tests use the ARCH variable, which is defined in the profile. They
> most certainly do not use the KEYWORDS or attempt to do any magic on the
> CHOST definitions.

Cool!  Now I know.  Inaccuracy in worldview corrected.  Thanks!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list