I am using the most recent /etc/portage/bashrc script here (is there a download location for this?) that allows a package.ldflags file. It doesn't work for me, what am I doing wrong? (see error msg below)

The other /etc/portage/package.* files are empty, created with touch. Is my syntax wrong? I tried various permutations of the GLOBALLDFLAGS variable, it didn't help whether it was there or not, or what format.

-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension supplied)
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
--help display this help and exit
--version output version information and exit

If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.

E-mail bug reports to: bonzini@gnu.org .
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
/etc/portage/bashrc: line 59: s/GLOBALLDFLAGS/-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -s/g: No such file or directory

I am using the most recent /etc/portage/bashrc script here (is there a download location for this?) that allows a package.ldflags file. It doesn't work for me, what am I doing wrong?

There isn't really a most recent version, just versions that different people have written (I think). Though if it doesn't work you could always use my version (also on the previous page.) Although it doesn't do the things outlined in smoked's post, the code is simpler - at least there're not any sed expressions for it to get choked up on.

Or... because I was bored, you could try this new fits-the-entire-script-within-a-80x24-console version. Though it's probably more likely to have more bugs:

without this modification per package *flags are added 3 times if used with global ones.

That's true, but with that modification it won't fit into a standard 80x24 console, which was the entire point of that version. (I don't care if it's a stupid goal.) It could probably be made better in other ways too (like all the things that smoked's version does.) That, and having the flags thrice doesn't change anything. Right. Someday perhaps a good version that fits within an 80x24 console... one can dream.

I want to use fairly aggressive flags (see below) and then filter for what breaks. Perhaps someone can save me some heartache and share with me packages that already break? You can post them here, or email me at enderandrew (at) gmail (dot) com

FYI: anything you change via bashrc files will only ever affect the bash side of portage, not the python side. FOr *FLAGS you can ignore that, but for FEATURES it's a important difference, you can only change some features via bashrc, others will simply be ignored there (e.g. buildpkg or collision-protect).

FYI: anything you change via bashrc files will only ever affect the bash side of portage, not the python side. FOr *FLAGS you can ignore that, but for FEATURES it's a important difference, you can only change some features via bashrc, others will simply be ignored there (e.g. buildpkg or collision-protect).

Not only is this true for most FEATURES but even for more basic things like CONFIG_PROTECT (Usually, one would like to delete everything when a package is deleted and not leave config-files lying around, especially, if they had never been modified - however, modifying/exporting CONFIG_PROTECT in /etc/portage/bashrc for "prerm" seems to have no effect).

Does anybody know a clean way to convince portage to "reread" FEATURES (or CONFIG_PROTECT)? In particular, is there e.g. another mechanism like /etc/portage/bashrc which could allow to introduce python code on a "per packet basis"? I only know of the other "hooks" /etc/portage/profile/profile.bashrc and /etc/portage/modules. While the former seems to be rather similar to /etc/portage/bashrc (I have not yet studied portage enough to understand the difference - maybe somebody can explain?), the latter perhaps *might* be used to write some hook in python. So maybe somebody with sufficient insight into the portage code knows a good place where and how to hook?

Does anybody know a clean way to convince portage to "reread" FEATURES (or CONFIG_PROTECT)? In particular, is there e.g. another mechanism like /etc/portage/bashrc which could allow to introduce python code on a "per packet basis"? I only know of the other "hooks" /etc/portage/profile/profile.bashrc and /etc/portage/modules. While the former seems to be rather similar to /etc/portage/bashrc (I have not yet studied portage enough to understand the difference - maybe somebody can explain?), the latter perhaps *might* be used to write some hook in python. So maybe somebody with sufficient insight into the portage code knows a good place where and how to hook?

Thanks for the answer. I feared so when looking briefly at the portage code. However, I hoped that there might be another trapdoor: After all, I was very impressed to see what can be done with /etc/portage/module: Like e.g. the cdb or the metadata_overlay http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1602 extensions. But maybe you consider these already as patches.

Can someone please explain how do set this up properly? I put the bashrc file in /etc/portage and I created an entry in /etc/portage/package.ldflags but it didn't seem to have any effect. i.e. I have something in my LDFlags that I don't want this particular application to use, so I put the entry in ldflags but didn't put any flags after it (which I assumed would be the same as doing LDFLAGS="" at the console before an emerge) but nothing changed. What am I doing wrong?

does this work also to overide the package build in cflags?? I mean that some packages dont want to emerge on my CFLAGS but use "safer" CFLAGS.
I use -Os and many packaged doesnt want to compile -Os, instead they compile -O2
For example: WINE, glibc, gcc, and many others... I understand that some packages arent supposed to compile Os due to errors, but not that much,,(why wine??)_________________Arch & Fluxbox & 2.6.24-rc-zen!!!!
robertek.brevnov.net

does this work also to overide the package build in cflags?? I mean that some packages dont want to emerge on my CFLAGS but use "safer" CFLAGS.
I use -Os and many packaged doesnt want to compile -Os, instead they compile -O2
For example: WINE, glibc, gcc, and many others... I understand that some packages arent supposed to compile Os due to errors, but not that much,,(why wine??)

No, if the ebuild strips the flags they will still be stripped. For getting around ebuilds overriding cflags you could always use an overlay, though you may want to be extra careful when overriding the sane defaults for things like glibc.

Well if no has anything to say about it and I don't know zilc about, I think I have to switch back to normal bashrc_________________"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler,
Linux User: #416714

How does one ovverride global cflags ysung these bashrc's? Just reading the thread it sounds as though these scripts are not capable of doing that. Am I wrong?_________________Ware wa mutekinari.
Wa ga kage waza ni kanau mono nashi.
Wa ga ichigeki wa mutekinari.

"First there was nothing, so the lord gave us light. There was still nothing, but at least you could see it."

I use -fvisibility-inlines-hidden in make.conf [for kde really] and I would like to leave it in there and be able to turn it off for wxGTK which apparently doesn't play nice with said flag. Besides it would be nice to be able to disable flags for specific items as it is _________________Ware wa mutekinari.
Wa ga kage waza ni kanau mono nashi.
Wa ga ichigeki wa mutekinari.

"First there was nothing, so the lord gave us light. There was still nothing, but at least you could see it."

I use -fvisibility-inlines-hidden in make.conf [for kde really] and I would like to leave it in there and be able to turn it off for wxGTK which apparently doesn't play nice with said flag. Besides it would be nice to be able to disable flags for specific items as it is

Many flags have anti-flags as well. -fno-visibility-inlines-hidden, if it comes after the -fvisibility-inlines-hidden in the GCC command, will disable -fvisibility-inlines-hidden. Though as thebigslide pointed out you can also leave off GLOBALCFLAGS.