Bug 241032

Summary:	net-libs/libotr: C(XX)FLAGS are ignored (at src_configure/compile)
Product:	Gentoo Linux	Reporter:	Diego Elio Pettenò (RETIRED) <flameeyes>
Component:	New packages	Assignee:	Gentoo Net-im project <net-im>
Status:	RESOLVED FIXED
Severity:	normal	CC:	arttuv69
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Diego Elio Pettenò (RETIRED) gentoo-dev

2008-10-10 11:11:41 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 Arttu Valo 2010-01-03 17:22:59 UTC

Bug #235990 has probably fixed this one, it might even be a duplicate.

Comment 2 Kevin McCarthy (RETIRED) gentoo-dev

2011-03-20 17:16:12 UTC

I've just checked both libotr-3.2.0 and libotr-3.1.0 and they both seem to respect CFLAGS. It looks like the the fixes from Bug #235990 took care of the problem, but this bug was never closed, therefore I'm closing this bug as RESOLVED FIXED.