[MacPorts] #27341: error: size of array '__curl_rule_01__' is negative

[MacPorts]

#27341: error: size of array '__curl_rule_01__' is negative
--------------------------+--------------------------------
  Reporter:  bhamilton@…  |      Owner:  macports-tickets@…
      Type:  defect       |     Status:  closed
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:  1.9.2
Resolution:  invalid      |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by larryv@…):

 Replying to [comment:4 philip@…]:
 > Surely you cannot say that one cannot have anything in /usr/local -
 > the compiler and linker only look into directories that are
 > explicitly specified on the command line, or perhaps are referenced in
 > a shell/environment variable.

 False. Any directories specified on the command line are prepended to the
 compiler’s default search path, which is not specified by an environment
 variable. More importantly, build systems (''a la'' Autotools) often take
 it upon themselves to search /usr/local. But that’s why
 [[FAQ#usrlocal|having stuff in /usr/local is unsupported]] ''generally''.
 That was not the actual problem here.

 > The real problem here is that the Makefile (provided by macports) is
 > itself to blame.

 Again, false. You’d know this if you’d actually bothered to read
 [[source:trunk/base/src/pextlib1.0/Makefile|the makefile]].

 > Here is the command line echoed from the Makefile:
 > {{{
 > ===> making all in src/pextlib1.0
 > gcc -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -Wextra -Wall
 -pedantic  -I/usr/local/include   -DHAVE_CONFIG_H -I.. -I.
 -I"/usr/include" -fno-common curl.c -o curl.o
 > In file included from /usr/local/include/curl/curl.h:35,
 >                  from curl.c:46:
 > /usr/local/include/curl/curlrules.h:143: error: size of array
 ‘__curl_rule_01__’ is negative
 > make[2]: *** [curl.o] Error 1
 > }}}
 > As you can see, the compiler is being explicitly directed to search
 > /usr/local/include. So, the problem is *not* that there is anything in
 > /usr/local/include, but rather that your own Makefile is
 > inappropriately telling the compiler to look there.

 False. Again. Here is the corresponding line from when I build MacPorts:
 {{{
 gcc -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -Wextra -Wall -pedantic
 -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common curl.c -o curl.o
 }}}
 The original poster almost certainly had CPPFLAGS or CFLAGS defined in the
 environment, which was picked up by the Makefile. This is unsupported, and
 the OP should have known better.

 > Closing this bug report as being "invalid" is not correct: the
 Makefile(s) in question should be fixed.

 Nope. Having CPPFLAGS defined in your environment, pointing to an include
 directory full of broken headers, is not correct. Makefiles should not
 have to jump through hoops to clear every possible automatic variable.
 It’s worth arguing that MacPorts base should sanitize the environment
 before running configure/make/make install, but the Makefile itself is
 perfectly correct to assume that it’s not being fed garbage.

-- 
Ticket URL: <https://trac.macports.org/ticket/27341#comment:5>
MacPorts <http://www.macports.org/>
Ports system for Mac OS