error: size of array '__curl_rule_01__' is negative

[bhamilton@…]

while running 'sudo port -d selfupdate', results in:

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
make[1]: *** [all] Error 1
make: *** [all] Error 1
shell command "cd /opt/local/var/macports/sources/rsync.macports.org/release/base && ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline && make && make install" returned error 2
DEBUG: Error installing new MacPorts base: shell command failed
    while executing
"macports::selfupdate [array get global_options] base_updated"
Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: shell command failed

Text file attached with output from the command.

[ryandesign (Ryan Carsten Schmidt)]

You have something (curl headers, at least) in /usr/local. It is not supported to have anything in /usr/local while using MacPorts because such software can interfere. Move or remove /usr/local and try again.

[philip@…]

Replying to ryandesign@…:

You have something (curl headers, at least) in /usr/local. It is not supported to have anything in /usr/local while using MacPorts because such software can interfere. Move or remove /usr/local and try again.

With all due respect, this is not an adequate response. 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. The real problem here is that the Makefile (provided by macports) is itself to blame. 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.

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

[larryv (Lawrence Velázquez)]

Replying to 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 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 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.

[philip@…]

Replying to larryv@…:

I'll forgo including all the previous back-and-forth so this is more readable...

My apologies for not looking at the Makefile directly...you're right, there is no explicit inclusion of /usr/local/include on the includes path. However, there may be, in my view, still some sort of problem here. I've a few decades' experience programming with Makefiles, and I'm currently mystified...

I ran into the same compilation error as the submitter of the original issue from a couple years ago - for me, it was during a "port selfupdate" or "port upgrade outdated" operation (sorry, don't recall which). This operation failed, and I used the "-d -v" flags to track down the specific location of the failure. This led me to the pextlib1.0 compilation, with the attendant inclusion of /usr/local/include on the include path. Of course I've checked my own shell and environment variables, and so far as I can tell, there is nothing set on CPPFLAGS or CFLAGS (or otherwise) for /usr/local or /usr/local/include in my defaults.

So, the question is: where did the gcc command, as issued from that Makefile, pick up /usr/local/include? I might speculate (with some significant danger of being wrong) that there might be something executed in the processing of the "selfupdate" or "upgrade outdated" that is adding /usr/local/include to the environment (seems possible, but unlikely)? Or, perhaps I had an older Makefile that actually did have /usr/local/include in it (seems very unlikely)? Or (given your reference to Autotools), is it possible that some previous, otherwise unrelated, run of one of the tools in that suite left detritus in my environment (if so, a pox on them)?

If you can let me know the best way (with the "port" command?) to force the same sort of recompilation that happened when I did the "selfupdate" or "upgrade outdated", I'd be happy to try to replicate the behavior, and track down the source if it recurs...

The general issue of /usr/local and macports is little problematic. As far as I can tell, macports puts everything in /opt/local, uses that path prefix for its various build/install operations, and modifies one's ~/.profile to add /opt/local/bin and /opt/local/sbin to the PATH env variable. Various open-source packages that are not provided by macports frequently default to use /usr/local for an install directory prefix. As well, it's been common practice for programmers on Unix-like systems to utilize /usr/local for building/installing software. I suppose in both cases, it should be possible to use yet a different path prefix (such as "/usr/myLocal" or "~/usr"), but having to do so simply to avoid collisions with macports seems less than ideal (hopefully that's not the case)...

In any case, any advice on tracking this down would be appreciated.

[larryv (Lawrence Velázquez)]

Not to seem too bureaucratic, but you’ll probably want to open a separate ticket about this, specifically about your stray /usr/local/include. You might get some fresh eyes on it that way, since at first glance (often the only glance, for some) this ticket looks like it’s about curl.

You might also consider sending an email to macports-users.

[sami.laine@…]

This error is easy to reproduce: cross-compile anything 32-bit on a 64-bit system. One easy example is to grab Castle Wolfenstein: Enemy Territory sources from GitHUB (​https://github.com/etlegacy/etlegacy.git) and trying to build it. The build will choke when doing a 32-bit cross compile, but finishes cleanly when compiling to 64-bit.

Some search engines also seem to reveal that this is actually a Curl problem, related to the way they define, e.g. CURL_SIZEOF_CURL_OFF_T in their headers.

Steps to reproduce:

1. sudo port install cmake curl git-core
2. git clone ​https://github.com/etlegacy/etlegacy.git && cd etlegacy
3. git submodule init && git submodule update
4. mkdir build && cd build && cmake gui .. && make

[sami.laine@…]

See also:

​http://www.youlikeprogramming.com/2010/05/curl-in-64-bit-operating-systems/ ​http://curl.haxx.se/mail/lib-2008-09/0051.html