expat fails to activate

[sofievalk@…]

DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: 'universal_variant no' specified, so not adding the default universal variant
DEBUG: Requested variant i386 is not provided by port apache-ant.
DEBUG: Requested variant macosx is not provided by port apache-ant.
DEBUG: Executing variant darwin provides darwin
--->  Activating expat @2.0.1_0
Error: The following dependencies failed to build: Xft2 expat fontconfig freetype zlib libiconv gperf pkgconfig xrender xorg-libX11 xorg-bigreqsproto xorg-inputproto xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-util-macros xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xtrans xorg-renderproto gawk gettext ncurses ncursesw gmp jpeg junit hamcrest-core apache-ant libmcrypt readline xorg-libXinerama xorg-libXext xorg-xineramaproto xorg-libXt xorg-libsm xorg-libice xpm
Error: Status 1 encountered during processing.

[ryandesign (Ryan Carsten Schmidt)]

There's no information here for me to go on. Please selfupdate and upgrade outdated ports to make sure you have the latest software, then clean and uninstall expat, then try installing again with the debug switch:

sudo port selfupdate
sudo port upgrade outdated
sudo port clean expat
sudo port -f uninstall expat
sudo port -d install expat 2>&1 | tee ~/Desktop/expat.txt
bzip2 ~/Desktop/expat.txt

If it fails again, attach the file expat.txt.bz2 from your desktop to this ticket so I can see what's actually happening.

[sofievalk@…]

The expat file

[sofievalk@…]

I have attached the file... because it failed again..

[ryandesign (Ryan Carsten Schmidt)]

Ok. The log says:

Image error: /opt/local/bin/xmlwf already exists and does not belong to a registered port.

So the question is, why does this file already exist? You can force the expat activation if you like:

sudo port -f activate expat

But this doesn't explain why you had bits of expat already on your system, nor does it guarantee you don't also have bits of other ports lying around that MacPorts doesn't know about either. Perhaps you had a previous installation of MacPorts that was not uninstalled correctly? If you can't explain why this file already existed, you may want to uninstall all of MacPorts using the ​instructions in the Guide, then start again, to ensure you don't have unexpected bits lying around.

[p.d.mosses@…]

Replying to ryandesign@…:

But this doesn't explain why you had bits of expat already on your system, nor does it guarantee you don't also have bits of other ports lying around that MacPorts doesn't know about either. [...]

I ran into exactly the same problem today, while trying to install graphviz (after port selfupdate and upgrading outdated ports).

I took a look at /Library/Receipts, which included these (all from the same time on April 30, 2009):

swi-prolog-5.6.64.pkg
zlib-1.2.3.pkg
readline-5.2.012.pkg
ncursesw-5.7.pkg
ncurses-5.7.pkg
libmcrypt-2.5.8.pkg
jpeg-6b.pkg
gmp-4.2.4.pkg
expat-2.0.1.pkg

I think that I used the package installer available at ​http://www.swi-prolog.org/download/stable. It states: "SWI-Prolog/XPCE 5.8.3 for MacOSX 10.5 (Leopard) on intel Installer with binaries created using Macports. Installs /opt/local/bin/swipl."

When I today ran port install -f graphviz, I noticed that it reported moving expat. zlib, ncursesw, ncurses and jpeg files - all of which were installed by SWI-Prolog... I'm not a developer and I don't know anything about the relationship between package installers and MacPorts, but it might be worht taking a close look at the cited SWI-Prolog package installer.

Hope this helps.

[ryandesign (Ryan Carsten Schmidt)]

The people over at SWI-Prolog use MacPorts to create their downloadable packages.

You must either use their packages, or use MacPorts; they cannot be used together.

[p.d.mosses@…]

I used their package only for SWI-Prolog. But it seems it installed expat for me too, and MacPorts tried to install that in connection with graphviz?

[ryandesign (Ryan Carsten Schmidt)]

Their package contained swi-prolog and all its dependencies, which includes expat. And yes, graphviz depends on expat as well.

I have sent a message to the SWI-Prolog guys asking them to stop distributing binaries that conflict with MacPorts and to instead pick a prefix other than /opt/local.

[p.d.mosses@…]

Replying to ryandesign@…:

I have sent a message to the SWI-Prolog guys asking them to stop distributing binaries that conflict with MacPorts and to instead pick a prefix other than /opt/local.

OK. Since they mentioned MacPorts and /opt/local/bin/swipl in connection with their package download, I assumed it was compatible with using MacPorts for installing other software. I think that they should have included a warning about the potential conflict, and directed MacPorts users to install using port.

It would be helpful to know if any other binary package installers are similarly in conflict with MacPorts.

[ryandesign (Ryan Carsten Schmidt)]

If they install into /opt/local, they conflict with a standard MacPorts install.

[p.d.mosses@…]

Right - but if SWI-Prolog isn't the only one, it might be helpful if MacPorts kept a list of those it knows about, together with hints for users on how to resolve port install problems due to common dependencies. Presumably using -f to force a port install can break the installed SWI-Prolog binaries?

Unfortunately SWI-Prolog has been distributing those binaries for some time (a year or more?) and the problem with them appears only when port tries to install some apparently unrelated package. SWI-Prolog changing its prefix for new downloads doesn't help MacPorts users who have already installed the old ones.

[ryandesign (Ryan Carsten Schmidt)]

Replying to p.d.mosses@…:

Right - but if SWI-Prolog isn't the only one, it might be helpful if MacPorts kept a list of those it knows about, together with hints for users on how to resolve port install problems due to common dependencies.

I'm not aware of any other binary packages that install into /opt/local. If you find any, request their distributors pick a different prefix so that they don't conflict with MacPorts. Our position on this matter will be if you have software in /opt/local that did not come from your MacPorts install, you should remove it; if you cannot identify all the parts that got put there, uninstall all of MacPorts per the instructions in the Guide, then start over.

Presumably using -f to force a port install can break the installed SWI-Prolog binaries?

Forcing activation of a port might cause problems for the standalone binary if the version of the port you force-activate is sufficiently different from the version the binary used. You should not need to be forcing activation. Don't use standalone binaries like SWI-Prolog's current binaries together with MacPorts. Pick one, and uninstall the other.

Unfortunately SWI-Prolog has been distributing those binaries for some time (a year or more?) and the problem with them appears only when port tries to install some apparently unrelated package. SWI-Prolog changing its prefix for new downloads doesn't help MacPorts users who have already installed the old ones.

Agreed. But it's not our fault and I don't feel it's our problem. Well, it becomes our problem when users file tickets, but they will be closed as invalid with the instruction to remove everything and start over.

[p.d.mosses@…]

Section 3.4.2 of the MacPorts Guide gives instructions on how to use the port command to create binary packages. It doesn't warn about any potential problems for MacPorts users when they install such binary packages. If the SWI-Prolog developers needed to pick a prefix other than /opt/local, shouldn't that have been mentioned in the Guide?

[ryandesign (Ryan Carsten Schmidt)]

Duplicate of #23110.