Ismail Dönmez wrote:
Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:
Ismail Dönmez <[EMAIL PROTECTED]> writes:
That was just an example, real life testcase shows that problem stems
from autoconf and its config.h. Projects end up defining things like
HAVE_STDLIB_H twice which is not harmful at all but now causes an error
if g++ is used.
Redefinitions with the same replacement list are not an error.

Ok but that still doesn't cover the general use of

#define PACKAGE_NAME foobar

We had to fix it ourselves for libffi as part of switching to autoconf 2.50+. The point is that installing config.h headers is broken by design -- and this is not something that the GCC community states. See for example

http://www.cygwin.com/ml/automake/2000-10/msg00116.html

"Unfortunately, people are being lulled into a false sense of security,
because installing config.h appears to work while it is an uncommon
practice.  Things will go downhill fast if this becomes common
practice -- imagine the chaos that we would have if gtk.h indirectly
#included a raw (i.e. with rewriting prior to installation) config.h,
which set up a whole bunch of HAVE_foo macros and VERSION's that you
don't want to cope with when you use libgtk.  Even worse what if the
gnome headers installed another conig.h with overlapping and
contradicting macros...."

which warned about this already 8 years ago.  Sweet.

Why not fixing the handful of packages with a /^#define PACKAGE/d, instead of adding -fpermissive to the 50 users of those broken packages?
Paolo

Reply via email to