(Sorry for resend but I really should have been paying attention to
which account I was sending from)
Recently a bug was filed against one of my packages with something I had
thought was impossible, package wasn't respecting CFLAGS:
https://bugs.gentoo.org/show_bug.cgi?id=426766
The reason I thought this was impossible, was because I have
- -frecord-gcc-switches in CFLAGS and CXXFLAGS (and it's a C++ application).
I opened up a bug to learn more, and learned a lot very quickly:
https://bugs.gentoo.org/show_bug.cgi?id=427654
As it turns out, it is documented inside portage itself that CFLAGS,
CXXFLAGS, FFLAGS, FCFLAGS all need to have -frecord-gcc-switches or the
QA mechanism doesn't work.
It would seem to me that we could get all these QA warning out of the
way very quickly by adding -frecord-gcc-switches to the *FLAGS in the
base profile (it appears to be platform agnostic but if I'm wrong we can
add it for supported arches).
YES, I admit this will cause users to see warnings for a short period of
adjustment, but it will be non-fatal and help us get all these packages
resolved much faster. It shouldn't be up to flameeyes to be the only
one doing QA like this (because I thought I was but clearly I've been
doing it wrong and I can't be alone in that).
Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On 07/22/2012 02:38 PM, Rick "Zero_Chaos" Farina wrote:
> It would seem to me that we could get all these QA warning out of the
> way very quickly by adding -frecord-gcc-switches to the *FLAGS in the
> base profile (it appears to be platform agnostic but if I'm wrong we can
> add it for supported arches).
Most users probably won't notice unless they have
PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa" or use the developer
profile which sets that automatically.
Also, the user's *FLAGS settings will override any settings from the
profile, unless the user does something like CFLAGS="${CFLAGS} foo bar".
--
Thanks,
Zac
07-23-2012, 12:44 AM
Diego Elio Pettenò
Detecting ignored *FLAGS
Il 22/07/2012 14:38, Rick "Zero_Chaos" Farina ha scritto:
> It would seem to me that we could get all these QA warning out of the
> way very quickly by adding -frecord-gcc-switches to the *FLAGS in the
> base profile (it appears to be platform agnostic but if I'm wrong we can
> add it for supported arches).
Ehm no that's not a good idea because it can actually cause problems.
Some ebuilds do s/-O2/${CFLAGS} s/gcc/$(tc-getCC)/ (in this order) and
then -frecord-gcc-switches will fail.
Other packages call ld directly, and then -frecord-gcc-switches in
LDFLAGS will fail...
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
07-23-2012, 05:30 PM
"Rick "Zero_Chaos" Farina"
Detecting ignored *FLAGS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/22/2012 08:44 PM, Diego Elio Pettenò wrote:
> Il 22/07/2012 14:38, Rick "Zero_Chaos" Farina ha scritto:
>> It would seem to me that we could get all these QA warning out of the
>> way very quickly by adding -frecord-gcc-switches to the *FLAGS in the
>> base profile (it appears to be platform agnostic but if I'm wrong we can
>> add it for supported arches).
>
> Ehm no that's not a good idea because it can actually cause problems.
> Some ebuilds do s/-O2/${CFLAGS} s/gcc/$(tc-getCC)/ (in this order) and
> then -frecord-gcc-switches will fail.
>
> Other packages call ld directly, and then -frecord-gcc-switches in
> LDFLAGS will fail...
>
Those are two very valid reasons why we can't add these to the profiles,
but do you have any suggestions on how we can get more than just
yourself running this QA?
Even something simply like detecting CFLAGS="-frecord-gcc-switches" set
but not FFLAGS and then teasing the user into fixing it would seem
worthwhile to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Il 23/07/2012 10:30, Rick "Zero_Chaos" Farina ha scritto:
>> >
> Those are two very valid reasons why we can't add these to the profiles,
> but do you have any suggestions on how we can get more than just
> yourself running this QA?
Add it to the dev profile (I think we have one?) via bashrc, then we
should have something. If something breaks on a dev box, I'd say the
best effort can be made to fix it.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
07-23-2012, 06:50 PM
"Rick "Zero_Chaos" Farina"
Detecting ignored *FLAGS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/23/2012 01:44 PM, Diego Elio Pettenò wrote:
> Il 23/07/2012 10:30, Rick "Zero_Chaos" Farina ha scritto:
>>>>
>> Those are two very valid reasons why we can't add these to the profiles,
>> but do you have any suggestions on how we can get more than just
>> yourself running this QA?
>
> Add it to the dev profile (I think we have one?) via bashrc, then we
> should have something. If something breaks on a dev box, I'd say the
> best effort can be made to fix it.
>
We do have a dev profile, and I agree that is a good place to start.
Is there a good way to add that to the dev profile? I'm mostly curious
if there is a way to do it without angering llvm/clang users?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On 07/23/2012 01:44 PM, Diego Elio Pettenò wrote:
> Il 23/07/2012 10:30, Rick "Zero_Chaos" Farina ha scritto:
>>>>
>> Those are two very valid reasons why we can't add these to the profiles,
>> but do you have any suggestions on how we can get more than just
>> yourself running this QA?
>
> Add it to the dev profile (I think we have one?) via bashrc, then we
> should have something. If something breaks on a dev box, I'd say the
> best effort can be made to fix it.
>
So are we all in agreement to add the needed flags stuff to the dev
profile? Anyone want to opt out of may I drop it in base?
I would REALLY like to cut down on things like what I saw when I
upgraded today:
* Messages for package app-emulation/emul-linux-x86-baselibs-20120520:
* Messages for package app-emulation/emul-linux-x86-db-20120520:
* QA Notice: Files built without respecting CFLAGS have been detected
* Please include the following list of files in your report:
* /usr/lib32/mysql/libmysqlclient_r.so.16.0.0
* /usr/lib32/mysql/plugin/ha_innodb_plugin.so.0.0.0
* /usr/lib32/mysql/libmysqlclient.so.16.0.0
* /usr/lib32/libodbccr.so.2.0.0
* /usr/lib32/libodbcinst.so.2.0.0
* /usr/lib32/libmyodbc5-5.1.6.so
* /usr/lib32/libodbc.so.2.0.0
* Messages for package app-emulation/emul-linux-x86-opengl-20120520:
* QA Notice: Files built without respecting CFLAGS have been detected
* Please include the following list of files in your report:
* /usr/lib32/libglut.so.3.9.0
* /usr/lib32/libGLESv1_CM.so.1.1.0
* /usr/lib32/libdrm_nouveau.so.1.0.0
* /usr/lib32/libGLEWmx.so.1.6.0
* /usr/lib32/egl/egl_gallium.so
* /usr/lib32/mesa/vmwgfx_dri.so
* /usr/lib32/mesa/nouveau_dri.so
* /usr/lib32/mesa/r300g_dri.so
* /usr/lib32/mesa/r300_dri.so
* /usr/lib32/mesa/r200_dri.so
* /usr/lib32/mesa/unichrome_dri.so
* /usr/lib32/mesa/savage_dri.so
* /usr/lib32/mesa/i965_dri.so
* /usr/lib32/mesa/sis_dri.so
* /usr/lib32/mesa/i965g_dri.so
* /usr/lib32/mesa/r600g_dri.so
* /usr/lib32/mesa/r128_dri.so
* /usr/lib32/mesa/nouveau_vieux_dri.so
* /usr/lib32/mesa/i915_dri.so
* /usr/lib32/mesa/i915g_dri.so
* /usr/lib32/mesa/i810_dri.so
* /usr/lib32/mesa/mga_dri.so
* /usr/lib32/mesa/swrast_dri.so
* /usr/lib32/mesa/tdfx_dri.so
* /usr/lib32/mesa/r600_dri.so
* /usr/lib32/mesa/swrastg_dri.so
* /usr/lib32/mesa/mach64_dri.so
* /usr/lib32/mesa/radeon_dri.so
* /usr/lib32/libEGL.so.1.0
* /usr/lib32/libdrm_radeon.so.1.0.0
* /usr/lib32/libkms.so.1.0.0
* /usr/lib32/libGLU.so.1.3.071100
* /usr/lib32/libglapi.so.0.0.0
* /usr/lib32/libGLEW.so.1.6.0
* /usr/lib32/libGLESv2.so.2.0.0
* /usr/lib32/libdrm.so.2.4.0
* /usr/lib32/libdrm_intel.so.1.0.0
* /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2
* Messages for package app-emulation/emul-linux-x86-xlibs-20120520:
* Messages for package app-emulation/emul-linux-x86-soundlibs-20120520-r2:
* QA Notice: The following files contain runtime text relocations
* Text relocations force the dynamic linker to perform extra
* work at startup, waste system resources, and may pose a security
* risk. On some architectures, the code may not even function
* properly, if at all.
* For more information, see http://hardened.gentoo.org/pic-fix-guide.xml
* Please include the following list of files in your report:
* TEXTREL usr/lib32/libmpg123.so.0.29.3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> I would REALLY like to cut down on things like what I saw when I
> upgraded today:
>
> * Messages for package
> app-emulation/emul-linux-x86-baselibs-20120520:
You are looking for QA_FLAGS_IGNORED.
--
Best regards,
Michał Górny
07-27-2012, 06:59 AM
"Rick "Zero_Chaos" Farina"
Detecting ignored *FLAGS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/27/2012 02:51 AM, Michał Górny wrote:
> On Fri, 27 Jul 2012 01:44:47 -0400
> "Rick "Zero_Chaos" Farina" <zerochaos@gentoo.org> wrote:
>
>> I would REALLY like to cut down on things like what I saw when I
>> upgraded today:
>>
>> * Messages for package
>> app-emulation/emul-linux-x86-baselibs-20120520:
>
> You are looking for QA_FLAGS_IGNORED.
>
I am more than aware of how the ebuilds could be fixed, my point was,
did the commiter ignore the warnings? Most likely not, most likely the
commiter didn't realize there was an issue because this isn't checked by
default, and it should be.
So, can we add what is necessary for this to work to the dev profile *FLAGS?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Rick "Zero_Chaos" Farina posted on Fri, 27 Jul 2012 01:44:47 -0400 as
excerpted:
> * Messages for package app-emulation/emul-linux-x86-baselibs-20120520:
>
> * QA Notice: Missing soname symlink(s):
> *
> * usr/lib32/libgnuintl.so.8 -> preloadable_libintl.so
> *
> * QA Notice: Missing soname symlink(s):
> *
> * usr/lib32/libgnuintl.so.8 -> preloadable_libintl.so
> *
> * QA Notice: Files built without respecting CFLAGS have been detected
> * Please include the following list of files in your report:
> * /lib32/libpam.so.0.83.1 * /lib32/libgpm.so.1.20.0
I'm unsure whether you realize that app-emulation/emul-linux-x86-* are
special-case and I'm missing something obvious (like some indication that
you're simply trying to shutup the warnings in this case), or whether
it's you missing the obvious, but just in case it's the latter I'll risk
publicly exposing the fact that I missed the former... =:^
The emul-linux-x86-* packages are pre-compiled 32-bit binaries there for
the convenience of amd64 multilib users who don't wish to run the 32-bit
chroot and separate 32-bit stage-based PM installation otherwise
necessary (in the absence of true multi-arch package-manager support) in
ordered to build the 32-bit libraries needed by some of their presumably
proprietary 32-bit-binary-only apps.
As such, they'll NEVER respect local CFLAGS, since they're not built
locally.
Similarly, various so-name symlinks (plus headerfiles, *.pc files, etc)
are omitted as they're only necessary when building reverse-deps, and
these are binary-only packages not intended to be built against, and
including these files would only increase the likelihood of conflict when
trying to build against the 64-bit versions.
As hinted above, to do the normal gentoo-ish build for the 32-bit version
of these libs on a 64-bit system, you follow the amd64 32-bit chroot
guide, installing a separately tracked and configured 32-bit x86 "stub
system" from 32-bit stages, thus ensuring all the necessary 32-bit
dependencies are available, etc, altho this 32-bit stub need not contain
system services, etc, unless you want to actually be able to boot to it,
since those are generally provided by the 64-bit side. Since that's a
LOT of extra work for the set of basic 32-bit libs that's all many will
use, the emul-linux-x86-* packages are available as a convenient (and
default) alternative for those that prefer to use them.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Detecting ignored *FLAGS
