#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 philip@…): Replying to [comment:5 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. -- Ticket URL: <https://trac.macports.org/ticket/27341#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS