Bug 241034 – net-libs/osptoolkit-3.3.4: C(XX)FLAGS are ignored (at src_configure/compile)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Diego Elio Pettenò (RETIRED) 2008-10-10 11:12:02 UTC]

I don't know the build system for this program (and this is a generic bug template so I cannot tell you which program exactly is), but my tests shows that it's not respecting CFLAGS (or CXXFLAGS) properly.

Please look into it, since it's important to respect user CFLAGS and CXXFLAGS.

Warning: this bug might look like a false positive because you actually have your CFLAGS being used; this happens if the CFLAGS are "set in stone" in the build system during src_unpack/src_prepare. While QA has not as of this moment expressed to me a preference, I'd sincerely suggest to avoid the set-in-stone approach, so that ebuild commands could work to reproduce the actual results.

To avoid the set in stone approach:

- consider just changing CFLAGS= to CFLAGS+= if the build system enables warnings;
- if the buildsystem does not use CFLAGS variable at all, in the sed use '$(CFLAGS)', single quoted, so that the CFLAGS variable is picked up;
- use '$(OPTCFLAGS)' in the sed and then use make OPTCFLAGS=$CFLAGS.

Thanks,
Diego

[Comment 1 Mounir Lamouri (volkmar) (RETIRED) 2009-02-17 03:43:52 UTC]

Created attachment 182300 [details, diff]
Fixing patch for osptoolkit-3.4.4

I wrote a patch fixing this bug and adding some missing die messages and change make instaal for emake install.

[Comment 2 Mounir Lamouri (volkmar) (RETIRED) 2009-02-17 03:44:21 UTC]

Created attachment 182302 [details, diff]
Fixing patch for osptoolkit-3.4.6

Same patch for 3.4.6

[Comment 3 Mounir Lamouri (volkmar) (RETIRED) 2009-02-17 03:45:48 UTC]

I assumed ebuilds have to be bumped to -r1 because is will force users to update and use their own CFLAGS.

[Comment 4 Mounir Lamouri (volkmar) (RETIRED) 2009-02-17 03:54:14 UTC]

I wrote 3.4.4 and 3.4.6, you had to see 3.3.4 and 3.3.6. The same for the patch names.
Sorry

[Comment 5 Jeremy Olexa (darkside) (RETIRED) 2009-02-17 05:11:51 UTC]

Probably best to just fix 3.3.6, since 3.3.4 has x86 stable and I don't want to get involved there.

Fixed in 3.3.6-r1, leaving bug open for 3.3.4 as a "known issue"

[Comment 6 Jeremy Olexa (darkside) (RETIRED) 2009-02-17 05:12:32 UTC]

and by "leaving bug open" I should mean it ;)

[Comment 7 Mounir Lamouri (volkmar) (RETIRED) 2009-04-15 00:29:00 UTC]

(In reply to comment #5)
> Probably best to just fix 3.3.6, since 3.3.4 has x86 stable and I don't want to
> get involved there.
> 
> Fixed in 3.3.6-r1, leaving bug open for 3.3.4 as a "known issue"
> 

3.3.6-r1 has been stabilized (see bug 265494) and 3.3.4 has been removed.
So, the bug is fixed.