Ticket #16271 (reopened defect)
e2fsprogs and ossp-uuid conflict on /opt/local/lib/libuuid.a
| Reported by: | raimue@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.6.0 |
| Keywords: | conflict | Cc: | macsforever2000@…, snc@…, michaelld@…, devans@…, arto.bendiken@… |
| Port: | e2fsprogs, ossp-uuid |
Description
---> Activating e2fsprogs @1.40.6_0 Error: Target org.macports.activate returned: Image error: /opt/local/lib/libuuid.a is being used by the active ossp-uuid port. Please deactivate this port first, or use the -f flag to force the activation.
I have currently no idea how to resolve this the correct way. The libraries are different.
Change History
comment:4 Changed 4 years ago by info@…
I would also be interested in a solution. Is it not possible to rename one of the to libs? I'm new to mac and the macports stuff, but if someone could give me a hint which is the common way to modify a port on the local machine the I would give it a try.
comment:6 Changed 4 years ago by raimue@…
- Keywords conflict added; e2fsprogs ossp-uuid removed
- Port changed from e2fsprogs to e2fsprogs, ossp-uuid
comment:7 Changed 4 years ago by raimue@…
Some research: FreeBSD simply marks the ports as conflicting. Debian and Gentoo rename the ossp-uuid library to libossp-uuid, which would also be a feasible solution for us.
comment:10 Changed 4 years ago by ryandesign@…
I have marked the ports as conflicting in r58096.
comment:11 Changed 4 years ago by toby@…
- Status changed from new to closed
- Resolution set to fixed
comment:12 follow-up: ↓ 13 Changed 3 years ago by revol@…
- Status changed from closed to reopened
- Resolution fixed deleted
This is wrong, the libuuid.a installed by e2fsprogs is different than ossp-uuid, there is no reason to mark it as a dependency. When trying to port GNU parted, it complains about missing libuuid (the one from e2fsprogs), which has a uuid_generate() call and uuid/uuid.h, whereas the ossp-uuid one has a different API and a uuid_create() call.
So those two definitely conflict, and e2fsprogs must install its own lib or packages depending on it won't work.
cf. the output of GNU parted configure:
checking for uuid_generate in -luuid... no
configure: error: GNU Parted requires libuuid - a part of the e2fsprogs package (but
sometimes distributed separately in uuid-devel or similar)
This can probably be found on your distribution's CD or FTP site or at:
http://web.mit.edu/tytso/www/linux/e2fsprogs.html
comment:13 in reply to: ↑ 12 Changed 3 years ago by revol@…
Likely if you check the current output of e2fsprog's configure it will complain about not finding uuid_generate(), which would explain it installs its own (different) libuuid, because the one you install as "dependency" doesn't suit it.
comment:14 Changed 3 years ago by raimue@…
Removed errorneous dependency in r70835.
To revive libuuid provided by e2fsprogs we would need to rename one of them. Other package management systems are renaming the one from ossp-uuid to libossp-uuid, but I am not sure if that requires further patching in dependents.
comment:17 Changed 3 years ago by jmr@…
- Cc devans@… added
The dependency has been re-added in r70930 — devans, do you believe the information in comment:12 is incorrect?
comment:18 Changed 3 years ago by devans@…
I'm sorry I just kind of blundered into this by trying to install e2fsprog and it failed because there was no external libuuid to link to. So I added the dependency without being aware of this controvery. My issue was that having e2fsprog installed was causing evolution-data-server to misconfigure.
What I observe is that with the configure.args set the way they are now, the internal building of the internal libuuid is disabled and an external lib is necessary. As the port was, the port failed to build due to lack of said external library.
Please feel free to change things as you like. I'll stay out of this one.