[MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

Mojca Miklavec mojca at macports.org
Tue Jun 23 14:21:17 PDT 2015

Dear everyone (but mostly other developers),

I think this was all just an unfortunate misunderstanding.

What I *believe* happened (but I have no way to know) is that the OP
probably tried to build a project cloned with git. That project
required autotools and failed to build because of the weird bug in
MacPorts (non-existent symlink), There must have been a confusion
solely due to the fact that building a "git project" triggered the

Please let's not go off-topic in useless discussions about "whether or
not macports should magically know which ports theoretically conflict
in case users mess up with their system in unpredictable ways".

On Tue, Jun 23, 2015 at 10:30 PM, Christopher David Ramos wrote:
> I do understand, however, that git is about version control of, usually,
> source code. That said, if building the source code of any given git
> project leads to conflicts with Macports, doesn't that constitute an
> undesirable conflict?

It would. But building the source code of *any given* git project
should not generally lead to conflicts.

The problem from the subject had to do with autotools failing to work
when a symlink points to non-existent location. Git has nothing to do
with autotools (other than the fact that many projects in subversion
or git ask users to run autotools first; while distributed tarballs
contain the configure script and autotools are not needed).

It was all just a misunderstanding. Maybe you were bitten by the
original problem (which is indeed some kind of a weird bug in
MacPorts) while compiling a project that you cloned with git, but the
failure itself is not related to git in any way (unless you
experienced other problems that you didn't describe yet).


More information about the macports-users mailing list