Ryan Hill | 1 Oct 01:27 2006

Re: [RFC] CFLAGS paragraph for the GWN

Lionel Bouton wrote:

> I'll wait and see if other devs are aware of common CFLAGS gotchas
> plaguing bugzilla.

Flags such as -fforce-addr and -fweb that change the way registers are
handled can often cause errors when compiling hand-optimised ASM on
architectures with a very limited number of registers (ie. x86).  This
turns up a lot in video libraries or graphic processing apps like
ffmpeg, xine-lib, or avidemux.


Jochen Maes | 1 Oct 01:32 2006

Re: OT noise (Was: Profile masking and profiles package.mask)

Danny van Dyk wrote:
> Am Samstag, 30. September 2006 19:02 schrieb Jakub Moc:
>> Mike Frysinger wrote:
>>> seriously jakub, stop responding ... you have nothing technical to
>>> offer to the issue at hand
>>> let the people who work on portage handle it
>>> -mike
>> Eh, the whole technical point here is that paludis behaviour differs
>> from portage (and differs from pkgcore, FWIW).
> This has little to do with why this change to the devmanual has been 
> done.
>> So, hiding the inconsistency via altering the profiles doesn't change
>> anything. Plus, the point of the bug's flame fest was that bugzilla
>> is not a proper place to request such behaviour changes, and
>> definitely not a reason for QA to mess with the profiles. Sticking
>> the stuff in package.mask won't make the inconsistent behaviour
>> vanish in any way, it will just hide it.
> It is not a behaviour change imho. The "packages" file changed
> its meaning subtly after introducing cascading profiles.
> As ciaranm already pointed out: It is not meant to mask "<"-like 
> versions anymore. It's meant to
> - Describe the system package set
(Continue reading)

Diego 'Flameeyes' Pettenò | 1 Oct 02:06 2006

Re: Profile masking and profiles package.mask

On Saturday 30 September 2006 19:39, Mike Frysinger wrote:
> isnt that the point of putting a comment above a mask ?
> # this package wont work on this profile
> bar/foo
Indeed, but the problem is that the masks are all normalised in one big mask. 
Which means that users might want to unmask certain versions found in the 
top-level profile.mask, and also unmask some of the packages masked in a 

> fbsd/packages:sys-freebsd/freebsd-mk-defs
> fbsd/package.mask:<nothing>
> fbsd/6.1/packages:<nothing>
> fbsd/6.1/package.mask:>=sys-freebsd/freebsd-mk-defs-6.2
> fbsd/6.2/packages:<nothing>
> fbsd/6.2/package.mask:<nothing>
Actually, you need to mask < versions, too ...

> so what you're arguing is that we should retain the existing behavior
> because users might try to unmask something properly ?  trying to protect
> users from shooting themselves in the foot by making the profile behavior
> more complicated is a waste of time
Uh, it's not "making the profile behaviour more complicated", it's "retaining 
the current behaviour of profiles".

But seems I'm in minority on this.
Still, if we're going to change this behaviour, it's the case to do it 
properly, by also updating the behaviour of portage itself, and document this 
properly (as in, give a reasoning for this change of behaviour).

Note to Danny: releng controls default-linux, okay, but there are other 
(Continue reading)

George Prowse | 1 Oct 02:37 2006

Re: [RFC] CFLAGS paragraph for the GWN

Lionel Bouton wrote:
> Hi, I just had an unpleasant experience with -ffast-math and GCC 4.1.1
> (it borked my LDAP authentication on several systems which worked with
> the same CFLAGS as long as GCC 3.4.6 was used).
> There is a lot of material out there about CFLAGS and Gentoo (google
> returns 387000 pages) but what's working for someone might not for
> another. There are flags that work for a GCC version and most ebuilds
> and don't work with another GCC version (my unfortunate experience) or
> some ebuilds. Flag combination/architecture/LDFLAGS might be an issue too.
> There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix
> was mentioned to me by robbat2) but they may not be advertised enough.
> I'd like to propose a paragraph to the GWN editor which presents some
> gotchas and good references on the subject.
> Here's a draft for review. You're welcomed to expand on the subject.
> --- Draft BEGIN ---
> <section>
> <title>CFLAGS</title>
> <body>
> <p>
> Being able to tune the CFLAGS is part of one of the core principles of
> Gentoo: let the user be in control. Being in control brings both
> benefits and problems and CFLAGS tuning is not an exception.
> </p>
> <p>
> The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the
(Continue reading)

Robin H. Johnson | 1 Oct 02:38 2006

Re: Re: [RFC] CFLAGS paragraph for the GWN

On Sat, Sep 30, 2006 at 04:37:05PM -0600, Ryan Hill wrote:
> I thought he wanted flags that broke upgrading between GCC 3.4 and 4.1.
>  tree-loop-linear wasn't in 3.4.  If you want flags that just break
> stuff with 4.1 you can include -ftree-vectorize.

> > The objective here was mainly to point out some things that users are
> > doing that are causing breakages, leading to bugs that are ultimately
> > marked INVALID after much tracing.
> Like using CFLAGS not on the Safe CFLAGS page?  ;)
Not really.
One needs to use some common sense as a developer in evaluating user
CFLAGS - because there are plenty of flags that are safe, but aren't
listed on that page.

Several years ago, I wrote a package that was the forerunner of the
'Safe CFLAGS' page - genflags. It was close to unmaintable at the time
however, so it's suffered a lot of bit-rot. With the advent of
libcpuinfo, and x86info being written, it stands a much better chance of
giving useful output, but that still does not supersede the common sense
statement above.


Robin Hugh Johnson
E-Mail     : robbat2 <at> gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Jason Stubbs | 1 Oct 09:01 2006

Re: Profile masking and profiles package.mask

On Saturday 30 September 2006 04:40, Diego 'Flameeyes' Pettenò wrote:
> This is a discussion to follow up bug #149508 [1].

Posted on the bug before noticing there was a -dev thread.

Just about everybody has the wrong idea here.

1) Specifying <sys-libs/glibc-2.4 in packages *does* mask >=sys-libs/glibc-2.4
and thus a corresponding entry in package.mask

2) What should be done is to specify >=sys-libs/glibc-2.4 and leave masking 
out altogether for packages

The reason that package.mask was added to profiles was so that masking of 
atoms in packages could be killed off and it could become just a list of 
required packages.

Like Marius said, using packages to both define what's required of "system" 
and for masking packages is bad design. That and the hope of eventually being 
able to kill off profiles/package.mask are the only reasons package.mask was 
introduced into profiles.

<snip stuff that Mike responded to correctly>

> I cannot find myself any reason for such a behaviour change, but I'm open
> to be proven wrong.

The original reason for specifying masking in both packages and package.mask 
(Continue reading)

Jason Stubbs | 1 Oct 09:20 2006

Re: Profile masking and profiles package.mask

On Monday 02 October 2006 16:03, Jason Stubbs wrote:
> 1) Specifying <sys-libs/glibc-2.4 in packages *does* mask
> >=sys-libs/glibc-2.4 and thus a corresponding entry in package.mask

... is redundant

Jason Stubbs

gentoo-dev <at> gentoo.org mailing list

Christian Heim | 1 Oct 12:06 2006

treecleaner maskings

# Christian Heim <phreak <at> gentoo.org> (01 Oct 2006)
# masking media-radio/ax25-tools for treecleaners, bug(s) 97275
# Pending removal Oct 29th

# Christian Heim <phreak <at> gentoo.org> (01 Oct 2006)
# masking x11-libs/buffy for treecleaners, bug(s) 103143
# Pending removal Oct 29th

# Christian Heim <phreak <at> gentoo.org> (30 Sep 2006)
# masking net-mail/quotient for treecleaners, bug(s) 149420
# Pending removal Oct 28th


Christian Heim <phreak at gentoo.org>
GPG key ID: 9A9F68E6
Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6

Your friendly treecleaner/mobile/kernel/vserver/openvz monkey
Mike Frysinger | 1 Oct 08:18 2006

Monthly Gentoo Council Reminder for October

This is your monthly friendly reminder !  Same bat time (typically the
2nd Thursday at 2000 UTC), same bat channel (#gentoo-council  <at> 
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:

gentoo-dev <at> gentoo.org mailing list

Duncan | 1 Oct 13:23 2006

Re: [RFC] CFLAGS paragraph for the GWN

Ryan Hill <dirtyepic.sk <at> gmail.com> posted efmrae$jff$1 <at> sea.gmane.org,
excerpted below, on  Sat, 30 Sep 2006 16:37:05 -0600:

> If you want flags that just break
> stuff with 4.1 you can include -ftree-vectorize.

Could you point me at some info on this one (-ftree-vectorize)?  It came
up on the amd64 list a week or so ago, when someone asked what I thought
of it and why I didn't have it in my cflags (which I had just explained). 
I said I didn't know enough about it to make a case either way, and as
such, didn't choose to use it.  However, after a bit of discussion, I
decided to add it to my cflags on a very experimental basis.  I haven't
experienced any issues with it, but then I haven't done any major
compiling since then either, only the routine updates.

If I had rather more info on it, therefore, particularly on why it might
break stuff, I'd be able to pass it on, telling the list and in particular
the guy that asked, why it's NOT a good thing to use.  Thus, point me at
it, if you got it.  Even something as simple as a list of bugs traced to
it would be useful as something I could point at, if that's what you are
basing your remark on.

Or does the problem not necessarily apply to amd64?  Even knowing that
would be useful.  I simply don't know anything much at all about it, beyond
a generally vague idea that it means using mmx/sse/whatever vector
instructions to parallelize loops.



(Continue reading)