libxml2 2.9.4 config error #54070 wontfix

[Ryan Schmidt]

On May 30, 2017, at 09:52, db wrote:

> On 30 May 2017, at 14:58, Ryan Schmidt wrote:
> 
>> What specific fix to you recommend?
> 
> I have no fix to recommend. My uneducated guess is that it's searching for /opt/local/lib/libreadline.6.dylib while I've just updated it to v7.

Yes. 

> Would that be non-fixable?

The fix is to upgrade the outdated thing that's still using version 6, in this case gawk. 

Note that gawk is not a declared dependency of the port you're building. 

The problem is that configure scripts of ports like the one you're building automatically look for gawk and other similar utilities. Even if the system version of awk would work, they prefer the MacPorts gawk if it's present. 

gawk is not the only utility this happens to. sed and grep are others. 

To fix this to your satisfaction, i.e. in a way that the user does not encounter an error message that they have to fix manually, we would have to modify every port that has such a configure script to tell it to only use the system versions of those utilities even if the MacPorts versions are installed. Alternately, we would have to make each of those ports declare dependencies on each of the utilities it opportunistically uses, even if they're not necessary. Either solution means modifying hundreds or thousands of ports, and ensuring that newly added ports follow this strategy too. So far, we've been unwilling to do this. 

Another solution is to use trace mode (the -t flag). Maybe one day MacPorts can default to doing so. For now, it reduces MacPorts performance by 50% so it's opt in rather than opt out. 

The problem does not happen often. It happens when a new library version of readline or ncurses is released. I think this has only happened a handful of times in the past decade so it hasn't been so inconvenient to just tell people to upgrade the offending port. Now that we distribute binaries the problem occurs even less frequently.