Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#64406 closed defect (invalid)

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

Reported by: mrkapqa Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: tiger Cc:
Port: libunistring

Description

  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.

Attachments (1)

libuni.log (787.8 KB) - added by mrkapqa 3 years ago.

Download all attachments as: .zip

Change History (6)

Changed 3 years ago by mrkapqa

Attachment: libuni.log added

comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: curl libunistring removed
Port: libunistring added; curl removed
Summary: (curl) Failed to activate libunistring: does not belong to a registered portlibunistring @0.9.10_0: unicase.h already exists and does not belong to a registered port

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.

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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.

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:4 Changed 3 years ago by kencu (Ken)

Resolution: invalid
Status: newclosed

comment:5 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.