[gentoo-dev] Common make.conf screwups?

[gentoo-dev] Common make.conf screwups?

[Ciaran McCreesh]

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

I've got some better vim syntax highlighting rules for make.conf lined
up to go into the next app-vim/gentoo-syntax. One of the things that
this lets me do is highlighting of (some kinds of) mistakes. What're the
most common screwups that people see? My current list is:

* CFLAGS: -0[123s] instead of -O[123s], -ffast-math globally

* USE: +foo flags

* ACCEPT_KEYWORDS: random duff entries (syntax is easy enough for me to
validate the whole thing)

* CHOST: there're certain settings that will cause glibc to fall over
and die that people who are used to debian/sparc will sometimes use

* MAKEOPTS: I'm kinda tempted to highlight "-j N" (where n is integer)

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Common make.conf screwups?

[Robert Moss]

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

A couple of CFLAGS that were never stable in any version of gcc:

-freduce-all-givs
-mfpmath=sse,387

The first flag will break things such as gcc, glibc, the kernel, 
binutils, bash and other nontrivial packages with every version of gcc 
I've ever tried (which is most of them). The flag has been denoted an 
experiment gone wrong and is no longer in CVS HEAD. The latter flag 
doesn't work properly and generates bad (sometimes segfaulting) code 
wherever SSE-related inline assembly is involved, and is slower than 
either -mfpmath=sse or -mfpmath=387 in 100% of cases according to those 
upstream.

But yeah, -freduce-all-givs is a far, FAR more dangerous global flag 
than -ffast-math, which can in theory give you a working (if not 
supported) system when set globally.

Also, perhaps highlight -fPIC in those cases where it shouldn't be used? 
Is that possible? Ehm. I don't mean that. Is that feasible? :-P

Rob

Ciaran McCreesh wrote:
> I've got some better vim syntax highlighting rules for make.conf lined
> up to go into the next app-vim/gentoo-syntax. One of the things that
> this lets me do is highlighting of (some kinds of) mistakes. What're the
> most common screwups that people see? My current list is:
> 
> * CFLAGS: -0[123s] instead of -O[123s], -ffast-math globally
> 
> * USE: +foo flags
> 
> * ACCEPT_KEYWORDS: random duff entries (syntax is easy enough for me to
> validate the whole thing)
> 
> * CHOST: there're certain settings that will cause glibc to fall over
> and die that people who are used to debian/sparc will sometimes use
> 
> * MAKEOPTS: I'm kinda tempted to highlight "-j N" (where n is integer)
> 

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

Re: [gentoo-dev] Common make.conf screwups?

[Ciaran McCreesh]

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

On Thu, 18 Nov 2004 20:34:22 +0000 Robert Moss <robmoss@gentoo.org>
wrote:
| Also, perhaps highlight -fPIC in those cases where it shouldn't be
| used? Is that possible? Ehm. I don't mean that. Is that feasible? :-P

What're the cases where it shouldn't be used? If it takes you more than
two lines to answer, probably not :)

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Common make.conf screwups?

[Robert Moss]

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

Well you definitely shouldn't have it in there if you're not using 
hardened. If you are using hardened I'm not sure...

Ciaran McCreesh wrote:
> On Thu, 18 Nov 2004 20:34:22 +0000 Robert Moss <robmoss@gentoo.org>
> wrote:
> | Also, perhaps highlight -fPIC in those cases where it shouldn't be
> | used? Is that possible? Ehm. I don't mean that. Is that feasible? :-P
> 
> What're the cases where it shouldn't be used? If it takes you more than
> two lines to answer, probably not :)
> 

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

Re: [gentoo-dev] Common make.conf screwups?

[Ned Ludd]

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

On Thu, 2004-11-18 at 16:58, Robert Moss wrote:
> Well you definitely shouldn't have it in there if you're not using 
> hardened. If you are using hardened I'm not sure...
> 
> Ciaran McCreesh wrote:
> > On Thu, 18 Nov 2004 20:34:22 +0000 Robert Moss <robmoss@gentoo.org>
> > wrote:
> > | Also, perhaps highlight -fPIC in those cases where it shouldn't be
> > | used? Is that possible? Ehm. I don't mean that. Is that feasible? :-P
> > 
> > What're the cases where it shouldn't be used? If it takes you more than
> > two lines to answer, probably not :)

CFLAGS=fPIC is not a screw up. No need to highlight.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded) Developer

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

[gentoo-dev] Re: Common make.conf screwups?

[Duncan]

Robert Moss posted <419D1B17.7060202@gentoo.org>, excerpted below,  on
Thu, 18 Nov 2004 21:58:47 +0000:

> Well you definitely shouldn't have it in there if you're not using
> hardened. If you are using hardened I'm not sure...
> 
> Ciaran McCreesh wrote:
>> On Thu, 18 Nov 2004 20:34:22 +0000 Robert Moss <robmoss@gentoo.org>
>> wrote:
>> | Also, perhaps highlight -fPIC in those cases where it shouldn't be
>> | used? Is that possible? Ehm. I don't mean that. Is that feasible? :-P
>> 
>> What're the cases where it shouldn't be used? 

In reply to Robert (because it's not obvious as it should be due to the
upside down quoting... grr!).

No, not all archs follow x86 (or whatever arch rules you are assuming)
rules. On some archs (amd64 comes to mind as that's what I use), -fPIC is
required.  Gentoo amd64 officially discourages it in make.conf, so as to
hilite ebuilds which do NOT set it so they can be patched to do so, but
it's required on the arch, regardless, whether it's configured in the
source, in the ebuild, or in make.conf, so on some archs anyway, it's NOT
wrong to have it in make.conf, hardened or not.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Common make.conf screwups?

[Robert Moss]

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

No, this is wrong. On amd64, you should *not* use -fPIC in make.conf. 
That's been policy since 2004.0. It is required that -fPIC is used for 
shared things (such as shared libraries) and it is required that -fPIC 
is not used for non-shared things (such as binaries). Thus, it must not 
be set in make.conf, otherwise you break this. If something does not 
compile without using -fPIC in CFLAGS, then that is a bug.

Hardened is different, however.

Duncan wrote:
> No, not all archs follow x86 (or whatever arch rules you are assuming)
> rules. On some archs (amd64 comes to mind as that's what I use), -fPIC is
> required.  Gentoo amd64 officially discourages it in make.conf, so as to
> hilite ebuilds which do NOT set it so they can be patched to do so, but
> it's required on the arch, regardless, whether it's configured in the
> source, in the ebuild, or in make.conf, so on some archs anyway, it's NOT
> wrong to have it in make.conf, hardened or not.
> 

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

[gentoo-dev] Re: Re: Common make.conf screwups?

[Duncan]

Robert Moss posted <41A10443.2070108@gentoo.org>, excerpted below,  on
Sun, 21 Nov 2004 21:10:27 +0000:

> No, this is wrong. On amd64, you should *not* use -fPIC in make.conf.
> That's been policy since 2004.0. It is required that -fPIC is used for
> shared things (such as shared libraries) and it is required that -fPIC is
> not used for non-shared things (such as binaries). Thus, it must not be
> set in make.conf, otherwise you break this. If something does not compile
> without using -fPIC in CFLAGS, then that is a bug.
> 
> Hardened is different, however.
> 
> Duncan wrote:
>> No, not all archs follow x86 (or whatever arch rules you are assuming)
>> rules. On some archs (amd64 comes to mind as that's what I use), -fPIC
>> is required.  Gentoo amd64 officially discourages it in make.conf, so as
>> to hilite ebuilds which do NOT set it so they can be patched to do so,
>> but it's required on the arch, regardless, whether it's configured in
>> the source, in the ebuild, or in make.conf, so on some archs anyway,
>> it's NOT wrong to have it in make.conf, hardened or not.

That's why I said "Gentoo officially discourages".

As for required, you are correct that it's "required" for shared libs on
amd64.  However, you are incorrect in that it's NOT "required that it be
OFF for unshared ELF executables, because the fact that I can type this
message and send it on such a system, in PAN, on KDE, on X, on Gentoo for
amd64, with -fPIC in my CFLAGS when I compiled a good share of
what's running, indicates that it cannot be a "requirement" for it to be
off in those cases in the same way that it's "required" to be on (on pain
of compile error) for libraries.

As I stated, "Gentoo officially discourages" setting it in CFLAGS, for bug
hunting and reporting reasons, but it works, and some of use use it even
on non-hardened (because hardened did NOT work here, couldn't run xorg)
because we like the idea of "position independent code" even in our
executables, with the fact that it prevents occasional hassles with
unpatched libs where it's definitely required, just a very pleasant side
effect.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Common make.conf screwups?

[Luke-Jr]

On Saturday 20 November 2004 8:17 am, Duncan wrote:
> No, not all archs follow x86 (or whatever arch rules you are assuming)
> rules. On some archs (amd64 comes to mind as that's what I use), -fPIC is
> required.  Gentoo amd64 officially discourages it in make.conf, so as to
> hilite ebuilds which do NOT set it so they can be patched to do so, but
> it's required on the arch, regardless, whether it's configured in the
> source, in the ebuild, or in make.conf, so on some archs anyway, it's NOT
> wrong to have it in make.conf, hardened or not.

As robmoss pointed out, -fPIC is good only for shared stuff.
Shared things will break on x86_64 if they don't have -fPIC, but that's not a 
x86_64-specific issue. x86 may not have visible problems with the lack of it, 
but it is still an issue and the arch simply works around it (with some 
inefficiency effects)

I don't think any of this is new info... I recall such a discussion a while 
back explaining about -fPIC...
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Common make.conf screwups?

[Brian Jackson]

On 7:45:29 pm 11/18/04 Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> I've got some better vim syntax highlighting rules for make.conf lined
> up to go into the next app-vim/gentoo-syntax. One of the things that
> this lets me do is highlighting of (some kinds of) mistakes. What're
> the most common screwups that people see? My current list is:

I don't know if you can detect it, but basing a var on another unset var,
i.e.

#PORTDIR=/usr/portage
then later in make.conf:
PKGDIR=${PORTDIR}/packages
or something similar

--Iggy

>
> * CFLAGS: -0[123s] instead of -O[123s], -ffast-math globally
>
> * USE: +foo flags
>
> * ACCEPT_KEYWORDS: random duff entries (syntax is easy enough for me
> to validate the whole thing)
>
> * CHOST: there're certain settings that will cause glibc to fall over
> and die that people who are used to debian/sparc will sometimes use
>
> * MAKEOPTS: I'm kinda tempted to highlight "-j N" (where n is integer)
>
> --
> Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Common make.conf screwups?

[Drake Wyrm]

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

At 2004-11-19T14:42:37+0000, Brian Jackson <iggy@gentoo.org> wrote:
> On 7:45:29 pm 11/18/04 Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> > I've got some better vim syntax highlighting rules for make.conf lined
> > up to go into the next app-vim/gentoo-syntax. One of the things that
> > this lets me do is highlighting of (some kinds of) mistakes. What're
> > the most common screwups that people see? My current list is:
> 
> I don't know if you can detect it, but basing a var on another unset var,
> i.e.
> 
> #PORTDIR=/usr/portage
> then later in make.conf:
> PKGDIR=${PORTDIR}/packages
> or something similar

I understand what you're thinking, but that's a bad example... $PORTDIR
is set to its default of "/usr/portage" before make.conf is parsed. Your
example would set $PKGDIR to "/usr/portage/packages" anyway. An
interesting quirk is found when one changes $PORTDIR without uncommenting
all the variables which use it. For example:

PORTDIR=/some/where/else
#PKGDIR=${PORTDIR}/packages

in one's make.conf leaves $PKGDIR set to "/usr/portage/packages".

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

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

Re: [gentoo-dev] Common make.conf screwups?

[Jason Stubbs]

At 2004-11-19T14:42:37+0000, Brian Jackson <iggy@gentoo.org> wrote:
> > I don't know if you can detect it, but basing a var on another unset var,
> > i.e.
> >
> > #PORTDIR=/usr/portage
> > then later in make.conf:
> > PKGDIR=${PORTDIR}/packages
> > or something similar

On Saturday 20 November 2004 07:00, Drake Wyrm wrote:
> I understand what you're thinking, but that's a bad example... $PORTDIR
> is set to its default of "/usr/portage" before make.conf is parsed.

It is set, but the "defaults" are not taken into account when make.conf is 
parsed. Each file is its own entity.

> Your example would set $PKGDIR to "/usr/portage/packages" anyway.

# cat /etc/make.globals |egrep "^(PORTDIR|PKGDIR)"
PORTDIR=/usr/portage
PKGDIR=${PORTDIR}/packages
# cat /etc/make.conf |egrep "^(PORTDIR|PKGDIR)"
PKGDIR="${PORTDIR}/packages"
# emerge info |egrep "^(PORTDIR|PKGDIR)"
PKGDIR="/packages"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""

> An interesting quirk is found when one changes $PORTDIR without uncommenting
> all the variables which use it. For example:
>
> PORTDIR=/some/where/else
> #PKGDIR=${PORTDIR}/packages
>
> in one's make.conf leaves $PKGDIR set to "/usr/portage/packages".

This is correct.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list