| 1 |
On 04/16/2013 04:53 PM, Neil Bothwick wrote: |
| 2 |
> On Tue, 16 Apr 2013 13:18:51 -0500, Paul Hartman wrote: |
| 3 |
> |
| 4 |
>>> It's unfortunate there's no tool to perform as revdep-rebuild, |
| 5 |
>>> except checking that, e.g. a package was built with the current |
| 6 |
>>> CHOST or CFLAGS set. The fact that I can run 'emerge --info |
| 7 |
>>> $atomname' to get the build environment for a given $atomname |
| 8 |
>>> tells me the system has enough information that this is |
| 9 |
>>> possible. I simply don't know the finer details of where all |
| 10 |
>>> this information lurks. But if I had such a tool, it would be of |
| 11 |
>>> immense use to me while installing new systems; no need to |
| 12 |
>>> emerge -e @world... |
| 13 |
>> |
| 14 |
>> Check out /var/db/pkg/$CATEGORY/$PKGNAME/ -- there are text files |
| 15 |
>> containing CFLAGS, CHOST and many others. You or someone like you |
| 16 |
>> should be able to hack together a simple script to look for |
| 17 |
>> differences. :) |
| 18 |
> |
| 19 |
> % source /etc/portage/make.conf % for f in /var/db/pkg/*/*/CFLAGS [[ |
| 20 |
> $(cat $f) == $CFLAGS ]] || echo $f |
| 21 |
> |
| 22 |
> It does give quite a few hits though, because ebuilds can strip out |
| 23 |
> flags. |
| 24 |
|
| 25 |
ebuilds should not generally be stripping out flags. Certainly there are |
| 26 |
occasional and valid cases, but they're pretty rare. Heck, last time I |
| 27 |
reported a bug where a flag was causing a build failure (since the |
| 28 |
package was using a compiler different from the system compiler), I was |
| 29 |
told it wasn't the packaging system's job to deal with that kind of bug. |
| 30 |
|
| 31 |
> Of course, that in itself may be an indication that you have |
| 32 |
> over-ricered your CFLAGS ;-) |
| 33 |
|
| 34 |
Or you might simply know what you're doing. |
| 35 |
|
| 36 |
http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS#Determining_available_processor_features |
| 37 |
|
| 38 |
Highly valuable if you're going to use distcc. |
Archives