[MacPorts] #27341: error: size of array '__curl_rule_01__' is negative
MacPorts
noreply at macports.org
Sat Mar 2 03:10:53 PST 2013
#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
More information about the macports-tickets
mailing list