Opened 10 years ago

Closed 9 years ago

#41271 closed defect (fixed)

libkml @1.2.0_1 conflicts with uriparser @0.7.2

Reported by: cooljeanius (Eric Gallager) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: ryandesign (Ryan Carsten Schmidt)
Port: libkml uriparser

Description

They both try to install a liburiparser.1.dylib:

x ./opt/local/include/kml/base/xml_element.h
x ./opt/local/include/kml/base/xml_file.h
x ./opt/local/include/kml/base/xml_namespaces.h
x ./opt/local/include/kml/base/xmlns.h
x ./opt/local/include/kml/base/zip_file.h
Error: org.macports.activate for port libkml returned: Image error: /opt/local/lib/liburiparser.1.dylib is being used by the active uriparser port.  Please deactivate this port first, or use 'port -f activate libkml' to force the activation.
DEBUG: Error code: registry::image-error
DEBUG: Backtrace: Image error: /opt/local/lib/liburiparser.1.dylib is being used by the active uriparser port.  Please deactivate this port first, or use 'port -f activate libkml' to force the activation.
    invoked from within
"throw registry::image-error "Image error: $file is being used by the active [$owner name] port.  Please deactivate this port first, or use 'port -f ac..."

Either this conflict should be fixed, or the ports should be marked as conflicting.

Change History (3)

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

Marked as conflicting for now. r113175

comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

I wasn't sure they were the same uriparser software, but I see now that it is: libkml includes a copy of uriparser 0.7.5. It's modified, but apparently the changes only deal with silencing some compiler warnings, so hopefully that doesn't matter; the fixes may even have been incorporated into newer versions of uriparser already.

So first we should update uriparser. Then we should see if we can get libkml to use the uriparser port instead of building and installing its own version.

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

Cc: ed@… removed
Resolution: fixed
Status: newclosed

Fixed in r136039.

libkml 1.2.0 always builds and installs its own copy of liburiparser; there is no configure argument to let it use an already-installed copy. A bug report was filed and a patch was provided to enhance the configure script to provide this, but it was never committed to the repository; the project has not been updated since 2010. Several developers have forked it to github but none have declared themselves to be authoritative and released new versions.

To use the patch, I had to regenerate the configure script. This uncovered additional bugs in the configure script when used with recent versions of autoconf, for which there were more bugs and uncommitted patches provided.

There is an additional problem in the configure script or Makefiles when used with recent versions of autotools which causes the build to fail when dependency tracking is on, which is the default when not building universal. No patch was provided for this so I just disabled dependency tracking.

The build system relies on liburiparser's .la file existing, which MacPorts deletes by default on OS X 10.9 Mavericks and later, so I had to modify uriparser not to delete its .la file.

Note: See TracTickets for help on using tickets.