libxml2 2.9.4 config error #54070 wontfix

classic Classic list List threaded Threaded
12 messages Options
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

libxml2 2.9.4 config error #54070 wontfix

db
I got basically the same error referenced in that ticket.

:info:configure config.status: creating libxml2.spec
:info:configure dyld: Library not loaded: /opt/local/lib/libreadline.6.dylib
:info:configure   Referenced from: /opt/local/bin/gawk
:info:configure   Reason: image not found
:info:configure ./config.status: line 1387: 82317 Done                    eval sed \"\$ac_sed_extra\" "$ac_file_inputs"
:info:configure      82318 Trace/BPT trap: 5       | $AWK -f "$ac_tmp/subs.awk" > $ac_tmp/out
:info:configure config.status: error: could not create libxml2.spec


deactivate gawk
upgrade gawk

works around the problem, as suggested by Ryan. I don't understand though, why is it not fixable.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

Ryan Schmidt-24
On May 30, 2017, at 06:53, db wrote:

>
> I got basically the same error referenced in that ticket.
>
> :info:configure config.status: creating libxml2.spec
> :info:configure dyld: Library not loaded: /opt/local/lib/libreadline.6.dylib
> :info:configure   Referenced from: /opt/local/bin/gawk
> :info:configure   Reason: image not found
> :info:configure ./config.status: line 1387: 82317 Done                    eval sed \"\$ac_sed_extra\" "$ac_file_inputs"
> :info:configure      82318 Trace/BPT trap: 5       | $AWK -f "$ac_tmp/subs.awk" > $ac_tmp/out
> :info:configure config.status: error: could not create libxml2.spec
>
>
> deactivate gawk
> upgrade gawk
>
> works around the problem, as suggested by Ryan. I don't understand though, why is it not fixable.

What specific fix to you recommend?
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

db
On 30 May 2017, at 14:58, Ryan Schmidt <[hidden email]> 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. Would that be non-fixable?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

Ryan Schmidt-24
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.


db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

db
On 30 May 2017, at 17:08, Ryan Schmidt <[hidden email]> wrote:
> 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.

Thanks, Ryan. Now wontfix makes sense. I suppose the explanation and the possible solutions could make it into the wiki.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

Mojca Miklavec-2
In reply to this post by Ryan Schmidt-24
On 30 May 2017 at 17:08, Ryan Schmidt <[hidden email]> wrote:

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

Another semi-weird solution would be to somehow declare a list of
"high priority" ports that always get updated first even if no other
port depends on them (either in the core or as a special keyword in
the Portfile).

Or introduce a concept of "soft dependencies". Those are dependencies
that are not needed (and not installed if absent), but should be
upgraded first in case they are present.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

Ryan Schmidt-24

> On May 30, 2017, at 11:23, Mojca Miklavec <[hidden email]> wrote:
>
> On 30 May 2017 at 17:08, Ryan Schmidt <[hidden email]> wrote:
>> 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.
>
> Another semi-weird solution would be to somehow declare a list of
> "high priority" ports that always get updated first even if no other
> port depends on them (either in the core or as a special keyword in
> the Portfile).

My initial impression of this idea is that I like it, for gawk, grep, gsed, and any others that are automatically searched for by default configure scripts. But remember that those ports have dependencies. Not many, but each of those dependencies would have to be handled by my previous suggestion, modifying each to ensure only the system version of those utilities is used.


> Or introduce a concept of "soft dependencies". Those are dependencies
> that are not needed (and not installed if absent), but should be
> upgraded first in case they are present.

If I understand correctly, you're suggesting that the port db was updating would be modified to indicate that it has a soft dependency on gawk, for example. I think that would have the same maintenance burden as the other two possibilities I mentioned above, which we are unlikely to want to undertake.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

Daniel J. Luke
On May 30, 2017, at 4:24 PM, Ryan Schmidt <[hidden email]> wrote:
>> Another semi-weird solution would be to somehow declare a list of
>> "high priority" ports that always get updated first even if no other
>> port depends on them (either in the core or as a special keyword in
>> the Portfile).
>
> My initial impression of this idea is that I like it, for gawk, grep, gsed, and any others that are automatically searched for by default configure scripts. But remember that those ports have dependencies. Not many, but each of those dependencies would have to be handled by my previous suggestion, modifying each to ensure only the system version of those utilities is used.

For this particular class of problems (autoconf picking up gawk/gsed, etc.) base could populate the environment with the system awk/sed etc. (ie base could do what the APR port does with configure.env).

Or, base could auto-add these soft dependencies for anything that does the 'normal 'configure' phase.

--
Daniel J. Luke



db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

db
In reply to this post by Ryan Schmidt-24
On 30 May 2017, at 17:08, Ryan Schmidt <[hidden email]> wrote:
> 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.

When running port upgrade outdated, couldn't base just deactivate those utilities, upgrade them first and unattended rebuild broken ports/files, which is what the user eventually does manually?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

Daniel J. Luke
On May 31, 2017, at 8:36 AM, db <[hidden email]> wrote:
> When running port upgrade outdated, couldn't base just deactivate those utilities, upgrade them first and unattended rebuild broken ports/files, which is what the user eventually does manually?

yes, but base doesn't currently know that it should do that (this thread contains some suggestions about how that might be possible).

I do think that improving trace mode is probably the best answer to this problem (and some other hard to solve problems).

--
Daniel J. Luke



db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

db
On 31 May 2017, at 15:16, Daniel J. Luke <[hidden email]> wrote:
> yes, but base doesn't currently know that it should do that (this thread contains some suggestions about how that might be possible).

I meant doing this from within base for the handful of utilities they are — no prio ports, no soft deps.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libxml2 2.9.4 config error #54070 wontfix

Daniel J. Luke
On May 31, 2017, at 11:12 AM, db <[hidden email]> wrote:
> On 31 May 2017, at 15:16, Daniel J. Luke <[hidden email]> wrote:
>> yes, but base doesn't currently know that it should do that (this thread contains some suggestions about how that might be possible).
>
> I meant doing this from within base for the handful of utilities they are — no prio ports, no soft deps.

Yes, Mojca mentioned this idea in:

https://lists.macports.org/pipermail/macports-users/2017-May/043384.html

--
Daniel J. Luke



Loading...