[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 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