# spezielle CFLAGS für einzelne Pakete

## LinuxTom

Hallo Leute,

der Titel sagt alles. Bei USE-Flags ist das ja kein Problem, doch geht das auch vom System her, so dass ich diese einzelnen Pakete nicht immer extra per Hand emergen muss? Ich finde dazu leider nichts.

----------

## Max Steel

Hmmm...

So sieht es bei mir aus:

```
$ cat /etc/portage/env/sys-libs/glibc

CFLAGS="${CFLAGS/-fstack-protector/-fno-stack-protector}"

CXXFLAGS="${CXXFLAGS/-fstack-protector/-fno-stack-protector}"

FEATURES="${FEATURES/distcc/-distcc}"

MAKEOPTS="-j6"
```

Reicht dir das als Antwort?

(Ich habe keine Ahnung ob man bestimmten Versionen auch noch verschiedene Parameter mitgeben kann.)

----------

## Christian99

im mv overlay gibt es auch noch app-portage/portage-bashrc-mv das erweitert das ganze ein bisschen.

----------

## LinuxTom

Das scheint genau die Erweiterung zu sein, die ich brauche. Mal sehen. Ist die Aufnahme ins Portage geplant?

----------

## mv

 *LinuxTom wrote:*   

> Ist die Aufnahme ins Portage geplant?

 

Kaum. Dazu ist das Ganze viel zu "hackish" und Missbrauch bei Bugreports kaum überschaubar.

----------

## kernelOfTruth

*subscribe*

das wollte ich schon lange anwenden (besonders bei glibc) ^^

----------

## toralf

 *kernelOfTruth wrote:*   

> *subscribe*
> 
> das wollte ich schon lange anwenden (besonders bei glibc) ^^

 Cool wird das Ganze, wenn Du Templates definierstg, z.B.:

```
# tail -v *

==> noparallel <==

MAKEOPTS="${MAKEOPTS} -j 1"

==> nosandbox <==

FEATURES="${FEATURES} -sandbox"

==> notest <==

FEATURES="${FEATURES} -test"

==> splitdebug <==

CFLAGS="-O2 -march=native -pipe -g -ggdb"                                                

CXXFLAGS="${CFLAGS}"                                                                      

FEATURES="${FEATURES} splitdebug"

==> userpriv <==

FEATURES="${FEATURES} userpriv"

```

und dann eine Datei(en) definierst in der Art :

```
# head /etc/portage/package.env/misc 

#       package.env

#

app-emulation/qemu-kvm                                          noparallel

app-emulation/virtualbox                                        noparallel

=app-office/akonadi-server-1.7.0                notest

app-office/akonadi-server       splitdebug

#       too long

dev-db/mysql                                    notest          userpriv

dev-lang/python                 splitdebug

=dev-lang/python-2.7.2-r3       splitdebug      notest

```

----------

## mv

 *toralf wrote:*   

> Cool wird das Ganze, wenn Du Templates definierstg, z.B.:
> 
> ```
> # tail -v *
> 
> ...

 

Drei Anmerkungen: Anscheinend geht das neuerdings auch ohne die Endung ".conf" in den Filenamen; aus Portabilitätsgründen würde ich aber trotzdem .conf anhängen, weil /etc/portage/env ja ggf. auch noch anderweitig genutzt werden kann.

FEATURES ist eine additive Variable. Es reicht also, FEATURES="-sandbox" oder FEATURES="splitdebug" (ohne "${FEATURES} ...").Für CFLAGS ist das trotzdem nur bedingt geeignet, weil Du dann für jedes, das Du verändern willst, eine eigene Datei brauchst. Zudem: Da Du keine Garantie hast, in welcher Reihenfolge die Files ausgeführt werden, funktionieren Kombinationen wie  */etc/portage/package.env wrote:*   

> foo/bar experimentelle_cflags.conf noflto.conf

  nicht unbedingt. Außerdem kannst Du das dann nicht mehr schnell bequem von der Kommandozeile aus überschreiben.

----------

## toralf

 *mv wrote:*   

> FEATURES ist eine additive Variable. Es reicht also, FEATURES="-sandbox" oder FEATURES="splitdebug" (ohne "${FEATURES} ...")

 Gilt das auch für MAKEOPTS ?

----------

## mv

 *toralf wrote:*   

>  *mv wrote:*   FEATURES ist eine additive Variable. Es reicht also, FEATURES="-sandbox" oder FEATURES="splitdebug" (ohne "${FEATURES} ...") Gilt das auch für MAKEOPTS ?

 

Nein. Die einzigen additiven Variablen sind FEATURES, USE, ACCEPT_KEYWORDS, und CONFIG_*. Und für USE und ACCEPT_KEYWORDS gibt es ja ohnehin eigene Files.

----------

## kernelOfTruth

@toralf, mv:

danke !

ich hab es jetzt schon einmal auf ein paar Pakete (darunter pulseaudio) angewendet und funktioniert ziemlich gut  :Smile: 

----------

## Yamakuzure

Habt Ihr mal in eure Build logs geschaut, ob das wirklich funktioniert? Ich habe früher mit /etc/portage/package.env einige Änderungen gemacht (-O3 bei sqlite und Python, ein paar Anwendungen mit Graphite und sowas) und mit portage-2.2* funktionierte das laut Build Logs auf einmal nicht mehr.

Bevor ich das Ganze mit dem sehr viel Arbeitsintensiveren weg /etc/portage/env/<Kategorie>/<Package> versuche, wüsste ich gerne, ob das auch wirklich hinhaut.

----------

## kernelOfTruth

 *Yamakuzure wrote:*   

> Habt Ihr mal in eure Build logs geschaut, ob das wirklich funktioniert? Ich habe früher mit /etc/portage/package.env einige Änderungen gemacht (-O3 bei sqlite und Python, ein paar Anwendungen mit Graphite und sowas) und mit portage-2.2* funktionierte das laut Build Logs auf einmal nicht mehr.
> 
> Bevor ich das Ganze mit dem sehr viel Arbeitsintensiveren weg /etc/portage/env/<Kategorie>/<Package> versuche, wüsste ich gerne, ob das auch wirklich hinhaut.

 

ich hab das ganze mit pulseaudio einmal ausprobiert und da funktioniert das ganze

das log wird kaum lügen, denke ich einmal:

 *Quote:*   

>  ---{ pulseaudio 1.99.2 }---
> 
>     prefix:                        /usr
> 
>     sysconfdir:                    /etc
> ...

 

eine elegante Variante ist auch: http://iquark.wordpress.com/2008/10/23/gentoo-per-package-flags/

so mach ich das zumindest (per symlinks)

portage: 2.2.0_alpha96

----------

## toralf

 *Yamakuzure wrote:*   

> Habt Ihr mal in eure Build logs geschaut, ob das wirklich funktioniert?

 ja

----------

## Yamakuzure

Ah fein, dann scheint ja nur der Weg über package.env nciht mehr zu funktionieren.

Der link ist auch gut, so ist der Aufwand nur noch etwas höher. Vielen Dank!   :Very Happy: 

----------

