Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[lukasz@…]

I cannot execute port upgrade outdated because of error while upgrading poppler.

This is my error:

sudo port upgrade outdated
Password:
--->  Computing dependencies for poppler
--->  Configuring poppler
Error: org.macports.configure for port poppler returned: autoreconf failure: command execution failed
Please see the log file for port poppler for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_sea.us.rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/main.log
Error: Unable to upgrade port: 1
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

Please see attached log file.

Unfortunately I was not able to execute port uninstall poppler, as it would remove all dependencies, and I wanted to avoid it. I did not find the "force" way.

[lukasz@…]

Log file.

[neverpanic (Clemens Lang)]

What does port provides /opt/local/share/aclocal/wxwin.m4 print? Is /opt/local/share/aclocal/wxwin.m4 a symlink, and if it is, is it broken (i.e. dangling, pointing to a non-existant file)?

I think some port used to provide this file, but did not register it, and now it's a leftover remnant that should just be deleted. I remember at least one previous instance where the same problem occured and was solved this way.

[neverpanic (Clemens Lang)]

Also, when reporting tickets against ports, please set the port field and Cc the maintainer, if any.

[lukasz@…]

Hello,

Result of port provides /opt/local/share/aclocal/wxwin.m4:

/opt/local/share/aclocal/wxwin.m4 is not provided by a MacPorts port.

Result of ls -l /opt/local/share/aclocal/wxwin.m4:

/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/share/aclocal/wxwin.m4

Which is a broken link.

I removed /opt/local/share/aclocal/wxwin.m4 and all went fine.

Thank you for such fast response.

[neverpanic (Clemens Lang)]

So the port that used to install /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/share/aclocal/wxwin.m4 is at fault here, because it didn't register the symlink.

Since this sounds like the wxWidgets-3.0 port, I'm Cc'ing their maintainers.

[mojca (Mojca Miklavec)]

The symlink /opt/local/share/aclocal/wxwin.m4 comes from port select wxWidgets wxWidgets-3.0. Compare with:

> ll /opt/local/bin/python
lrwxr-xr-x  1 root  admin    24B 21 jan  2012 /opt/local/bin/python -> /opt/local/bin/python2.7

> port provides /opt/local/bin/python
/opt/local/bin/python is not provided by a MacPorts port.

> sudo port -f deactivate python27

> ll /opt/local/bin/python
lrwxr-xr-x  1 root  admin    24B 21 jan  2012 /opt/local/bin/python -> /opt/local/bin/python2.7

> /opt/local/bin/python --version
-bash: /opt/local/bin/python: No such file or directory

This is the second error report with exactly the same symptoms I've heard about recently.

Maybe someone should "revisit" the "port select" code.

Port select aside, it might be helpful to install that single file (/opt/local/share/aclocal/wxwin.m4) unconditionally (by some standalone port which would then be a dependency of all wxWidgets-based ports), but it seems like a tiny bit of an overkill to me if a port would install just that single file.

[lukasz@…]

Cc Me!

[lukasz@…]

Cc Me!

[dbevans (David B. Evans)]

I was a bit confused at first by the discussion here but after some experimentation I was able to reproduce the error.

Restating the situation:

The configuration error here is due to the fact that, at the point of failure, a broken symlink is installed in /opt/local/share/aclocal which aclocal will not tolerate. The result is that any port, not just poppler, that uses aclocal (typically invoked by autoreconf) in the configuration process will fail.

In this case, the symlink in question is

$ ls -l /opt/local/share/aclocal/wxwin.m4
lrwxr-xr-x  1 root  admin  95 May 18 06:15 /opt/local/share/aclocal/wxwin.m4 -> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/share/aclocal/wxwin.m4

which is typically created by the commands

$ sudo port install wxWidgets-3.0
$ sudo port select wxWidgets wxWidgets-3.0

or

$ sudo port install wxWidgets-2.8
$ sudo port select wxWidgets wxWidgets-2.8

At this point deactivating the target port will break the symlink.

The following command sequence will recreate the reported issue

$ sudo port install wxWidgets-3.0
$ sudo port select wxWidgets wxWidgets-3.0
$ sudo port deactivate wxWidgets-3.0
$ sudo port install poppler

As reported removing the broken symlink will heal the problem. Rather than doing this manually I would suggest just deselecting the deactivated port.

$ sudo port select wxWidgets none

It's interesting to note that this command will now appear to fail as follows

Selecting 'none' for 'wxWidgets' failed: symlink: /opt/local/etc/select/wxWidgets/current -> none: file already exists

but the symlink is, in fact, removed. It appears that the 'port select' code is smart enough to set its selection to none when the selected port is deactivated but not smart enough to actually remove the symlinks associated with the old selection.

[dbevans (David B. Evans)]

Replying to mojca@…:

Port select aside, it might be helpful to install that single file (/opt/local/share/aclocal/wxwin.m4) unconditionally (by some standalone port which would then be a dependency of all wxWidgets-based ports), but it seems like a tiny bit of an overkill to me if a port would install just that single file.

This won't work because wxwin.m4 is produced by both wxWidgets-2.8 and wxWidgets-3.0 and the two versions are quite different. This is apparently why wxwin.m4 was added to the wxWidget-select base file. It's a point of conflict between the two versions.

If legacy wxWidgets-2.8 could be removed, wxWidgets-3.0 could just install wxwin.m4 in /opt/local/share/aclocal and be done with it.

[larryv (Lawrence Velázquez)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

At this point we consider it a user error to deactivate or uninstall a port that you have selected with "port select". Perhaps MacPorts base should be modified to prevent you from deactivating or uninstalling a port that you've selected.

[dbevans (David B. Evans)]

That's a possible solution, particularly if the error message tells you what to do (similar to activate errors, deactivating required dependencies, etc).

[mojca (Mojca Miklavec)]

Replying to ryandesign@…:

At this point we consider it a user error to deactivate or uninstall a port that you have selected with "port select".

This is like saying that deactivating a dependency of another port is considered a user error. What if users simply forget that they ever selected that port?

I would say that deactivation/uninstallation should also (automatically?) remove symlinks to foo-bar, but I'm not sure what the behaviour should be in this particular scenario:

port select foo foo-bar
port deactivate foo-bar
port activate foo-bar

Should foo still point to foo-bar or not?

(Ideally I would imagine some kind of "dormant symlinks". The symlinks that are gone while the port is deactivated, but are set back in place when the port is activated/installed again. However that is probably not something easy to implement, so some compromise is needed.)

Perhaps MacPorts base should be modified to prevent you from deactivating or uninstalling a port that you've selected.

This could be another solution. (But -f would probably override that? Would upgrading the port still work as expected?)

Does anyone know why autotools are so picky about broken symlinks?

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

Replying to ryandesign@…:

At this point we consider it a user error to deactivate or uninstall a port that you have selected with "port select".

This is like saying that deactivating a dependency of another port is considered a user error. What if users simply forget that they ever selected that port?

All I was trying to say is that there is nothing unusually broken about the user's system; it's simply that the user deactivated a port that had been selected. MacPorts should be improved to do something different if you attempt to deactivate a selected port. Same thing if you attempt to deactivate a loaded port, which currently also proceeds without complaint, with possibly unexpected results.

I would say that deactivation/uninstallation should also (automatically?) remove symlinks to foo-bar, but I'm not sure what the behaviour should be in this particular scenario:

port select foo foo-bar
port deactivate foo-bar
port activate foo-bar

Should foo still point to foo-bar or not?

Simplest would be to delegate the responsibility to the user by preventing deactivation, unless forced.

Perhaps MacPorts base should be modified to prevent you from deactivating or uninstalling a port that you've selected.

This could be another solution. (But -f would probably override that? Would upgrading the port still work as expected?)

Sure, allowing it to be forced seems to be in line with the idea that forcing should only be done by those who understand the consequences. It would be easier for users to understand the consequences if we explained them better in the error messages.

Agreed, attention needs to be paid to ensure that upgrade still work without complaint, and also in the case of auto-loaded ports (like certsync). In the case of manually-loaded ports (all the rest of the ports that use the startupitem keywords), something also needs to be done. Otherwise we have users who, say, upgrade mysql56, but the old version is still loaded and running. We should at least print a message reminding the user to reload the port at some point. Not sure we should necessarily do it for the user, since they may want more control over when it happens.

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #48052.

[m74z00219@…]

I tried removing the symlink to wxwin.m4, but install still fails. I think my problem extends to the fact that I've been fooling around with git (from macports). The log refers to a list of items that were not installed by Macports...or at least not registered to have been installed by Macports.

Actually, after uninstalling some git repo related stuff (sudo make uninstall), I was successfully able to install encfs -- thanks!

Is this typical of git repo project installations to interfere with Macports?

[ryandesign (Ryan Carsten Schmidt)]

Replying to m74z00219@…:

I tried removing the symlink to wxwin.m4, but install still fails. I think my problem extends to the fact that I've been fooling around with git (from macports). The log refers to a list of items that were not installed by Macports...or at least not registered to have been installed by Macports.

Actually, after uninstalling some git repo related stuff (sudo make uninstall), I was successfully able to install encfs -- thanks!

Is this typical of git repo project installations to interfere with Macports?

The method of software distribution (i.e. from a git or hg or svn or cvs or bzr repository, or from a tarball download) should have no bearing on whether a project interferes in some way with MacPorts. You'll have to be more specific about the problem you're experiencing, if you still need help with it, but it sounds like it's not related to this ticket, and if it's something you're doing outside of MacPorts (using "make" for example) then it sounds like it's not related to MacPorts.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #48100.

[m74z00219@…]

Replying to ryandesign@…:

Replying to m74z00219@…:

I tried removing the symlink to wxwin.m4, but install still fails. I think my problem extends to the fact that I've been fooling around with git (from macports). The log refers to a list of items that were not installed by Macports...or at least not registered to have been installed by Macports.

Actually, after uninstalling some git repo related stuff (sudo make uninstall), I was successfully able to install encfs -- thanks!

Is this typical of git repo project installations to interfere with Macports?

The method of software distribution (i.e. from a git or hg or svn or cvs or bzr repository, or from a tarball download) should have no bearing on whether a project interferes in some way with MacPorts. You'll have to be more specific about the problem you're experiencing, if you still need help with it, but it sounds like it's not related to this ticket, and if it's something you're doing outside of MacPorts (using "make" for example) then it sounds like it's not related to MacPorts.

While my original ticket (#48052) was rightly marked duplicate, it turned out that my inability to install encfs was two-fold -- the broken / unregistered symlink from wxWidgets and Git project compilations.

You're right on that it was the "making" that caused the issue, so in certain respects the conflicting software was my fault. That said, Macports does host a Git port, which is a software distribution platform. There is no indication / warning that Git projects involving compilation may install libraries that might interfere with Macports. In my opinion, this echos the debate happening above regarding the dividing line between user and maintainer responsibility.

Maybe it is warranted that Macports add a disclaimer to the Git port? Or, perhaps a guide to preventing conflicts with Macports when building Git projects?

[larryv (Lawrence Velázquez)]

I will reply to this on macports-dev, as it’s off-topic for this ticket.

[m74z00219@…]

Replying to larryv@…:

I will reply to this on macports-dev, as it’s off-topic for this ticket.

Thank you. Just subbed to the dev mailing list. Hopefully I didn't miss your reply already!

[larryv (Lawrence Velázquez)]

Sorry, I forgot to update my comment. I replied on macports-users, not macports-dev. I also addressed it to you directly, so you should have received it already.

[m74z00219@…]

Replying to larryv@…:

Sorry, I forgot to update my comment. I replied on macports-users, not macports-dev. I also addressed it to you directly, so you should have received it already.

NP, though I still probably missed it. I subscribed to both macports-dev and macports-users mailing lists, though haven't received a response. So, I tried searching the archives, without luck.

Would you mind pointing me to your post?

Also, I would like to report that I can no longer launch wxmaxima directly. It'll launch if I use "open /path/to/wxmaxima.app," though not just by inputting "wxmaxima" as with other ports. Inputting "maxima" works just fine. Why might this be? I figure it has something to do with the removal of the above symlink and I know for a fact that "/Applications/MacPorts/" was never part of my PATH variable. Even so, I did try, in succession, adding "/Applications/MacPorts/" and "/Applications/MacPorts/wxMaxima.app" to my PATH and still it would not launch with "wxmaxima."

Here's some other stuff I tried. I "sudo port selfupdate" and "sudo port upgrade outdated". I did it once more just to be sure. Unfortunately, the problem persists.

Initially, I also had a problem with wxmaxima not being able to connect to maxima. This was resolved by making sure that wxMaxima was listening to the default port of xmaxima. Or, at least I think that's what did it. Actually, I just played around with the port option and apparently it still works, so...mystery. It connects so whatever.

I thought briefly about nuking my Macports installation, but that seems like overkill as it seems that the problem is just with maxima. Honestly, I'm so confused. There's also xmaxima -- where does that fit it in??

To sum up, what might explain the inability to launch wxmaxima from command line?

Here's my PATH

PATH=/opt/local/bin:/opt/local/sbin:/opt/local/etc/php56:/opt/local/apache2/bin:/opt/local/lib/mysql56/bin:~/bin:~/.composer/vendor/bin:${PATH}

Thanks!

[larryv (Lawrence Velázquez)]

Replying to m74z00219@…:

Would you mind pointing me to your post?

​mp-users:2015-June/038796

Also, I would like to report that I can no longer launch wxmaxima directly.

Please open a separate ticket for this.

[m74z00219@…]

Replying to larryv@…:

Replying to m74z00219@…:

Would you mind pointing me to your post?

​mp-users:2015-June/038796

Also, I would like to report that I can no longer launch wxmaxima directly.

Please open a separate ticket for this.

Thank you, I will do so.

[lukasz@…]

Cc Me!

[lukasz@…]

Cc Me!

[m74z00219@…]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #46334.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #49127.

[mojca (Mojca Miklavec)]

I would be very grateful for some feedback and testing of #50768.

It's not providing the proper for this particular problem, but it avoid the most common mode of failure. I would like to commit the changes as soon as possible, so that I can add further wxWidgets ports (like wxWidgets 3.1) and changes.

[mojca (Mojca Miklavec)]

I hope to have fixed the problem with wxwin.m4 in r146366 (which of course doesn't mean that the original problem is solved).

[keybounce]

Cc Me!

[keybounce]

Replying to ryandesign@…:

At this point we consider it a user error to deactivate or uninstall a port that you have selected with "port select". Perhaps MacPorts base should be modified to prevent you from deactivating or uninstalling a port that you've selected.

Shouldn't "deactivating a selected port" coincide with "select 'none' as a followup"?

I.e.: If I have python32 selected as my python, and I deactivate python32, should that make "none" the current python? (If I understand the issue correctly, this is what triggers it, right?)

Equally, if I install python33, and there is no python selected, shouldn't python33 select itself as the python?

So, if I have python32 installed and selected, and upgrade to 33, 32 should deactivate, triggering "none", then 33 activates, and selects.

Would this approach solve both this issue and the semi-obvious related one of "I installed 33, but now things break with no active python"?

[ryandesign (Ryan Carsten Schmidt)]

Replying to keybounce@…:

Replying to ryandesign@…:

At this point we consider it a user error to deactivate or uninstall a port that you have selected with "port select". Perhaps MacPorts base should be modified to prevent you from deactivating or uninstalling a port that you've selected.

Shouldn't "deactivating a selected port" coincide with "select 'none' as a followup"?

I.e.: If I have python32 selected as my python, and I deactivate python32, should that make "none" the current python? (If I understand the issue correctly, this is what triggers it, right?)

That would be one way of handling it. But maybe the user forgot that they had selected, say, a particular python. Maybe it's better to do what I suggested, and make deactivating a port that is selected an error. That way the user is in control of deselecting it before deactivating it.

Equally, if I install python33, and there is no python selected, shouldn't python33 select itself as the python?

No. MacPorts doesn't distinguish between a port installed as an incidental dependency and one the user deliberately installed. Just because the user installed a port that happened to use python35 somewhere in its build system doesn't mean the user wants "python" to become a simlink to python3.5.

So, if I have python32 installed and selected, and upgrade to 33, 32 should deactivate, triggering "none", then 33 activates, and selects.

Note that these are separate ports: python32, python33. There is no "upgrade to 33". There is: install python33. It can coexist with python32. Just because a user installs python33 does not imply that they no longer want to use python32. We feel the user should be in control of what version of python the "python" symlink points to; the user indicates that preference by manually running "port select".

[lukasz@…]

Cc Me!

[DavidBAEpstein]

Cc Me!

[DavidBAEpstein]

Cc Me!

[DavidBAEpstein]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Duplicate of #31702.