libunistring @0.9.10_0: unicase.h already exists and does not belong to a registered port

[mrkapqa]

  Activating libunistring @0.9.10_0
Error: Failed to activate libunistring: Image error: /opt/local/include/unicase.h already exists and does not belong to a registered port.  Unable to activate port libunistring. Use 'port -f activate libunistring' to force the activation.
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_libunistring/libunistring/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port curl failed

This happened on Mac OS X Tiger 10.4.11.

Thank you.

[ryandesign (Ryan Carsten Schmidt)]

Only you can answer why unicase.h already exists on your system when MacPorts is telling you that it did not put it there. Maybe you or some other installer you ran installed libunistring into the MacPorts prefix at some point. You can force the activation of libunistring to replace your unregistered unicase.h (and probably many other files) with libunistring's unicase.h (and probably many other files) but if you can't explain how an unregistered unicase.h came to be on your system, it's possible or likely that you may encounter this problem with other ports in the future.

[mrkapqa]

thanks, i dont really know what to say, but i found this package here on my computer, probably by installing it it could have put files into place "MPlayer-1.3.0_3_OSX_Tiger.mpkg" or "qt4-mac-4.8.7_5.mpkg" at this point i will probably delete the macports installation and start anew, as safest bet.

[kencu (Ken)]

there have been people excited about building ports in MacPorts and then putting the packages up on MacRumors or Macintosh Garden. They are supposed to use a custom prefix for this, but rarely seem to. Causes all kinds of mess.

You can save all your built ports, wipe your installation, and then reinstall them. Check out the guide section on sharing built ports. I do this.

You can also run a bash command to iterate over your libs and headers and tell you which ones don’t belong to any port. I do this too if I’m curious.

[kencu (Ken)]

debian has a tool called cruft that does this procedure for you:

​https://wiki.debian.org/Cruft

you could try writing such a thing for macports, or coding something into “port doctor” to do it.