# kde4 installation fails, libiodbc-3.52.7 conflicts with unixODBC-2.3.0



## dheerajsuthar (Jun 20, 2010)

Hi!

FreeBSD on my machine is: FreeBSD 8.0-RELEASE-p3. It's completely updated with freebsd-update and ports updated with `portsnap update`.

I tried to install KDE4 (through ports) and got following errors during `make`:

```
libiodbc-3.52.7 conflicts with installed package(s): 
      unixODBC-2.3.0
```
I chose default options during `make config-recursive`.

Now, should I remove the said package? But will it not make installed packaged dependent on it unstable? Or is there any other way?

Kindly help me on this issues as I am getting the same problem while installing many other ports too. Should I go ahead and remove conflict packages in such cases?

Thanks in advance.


----------



## Dereckson (Jun 21, 2010)

Hi,

I had the same issue on FreeBSD 8.0 installing GNOME, then KDE4. Here the fix and how to solve this kind of issues:

(1) We need a general understanding of the problem. A google search on unixodbc and libiodbc explains its two drivers doing the same job, on a rather compatible way.

(2) We need a local understanding of the problem, ie here "what port uses this unixODBC?". To get the answer, *pkg_delete unixODBC-2.3.0* (pkg_delete won't delete anything used by other packages). It gives a list of the packages using the library. On my computer, it were:


```
scherzo# pkg_delete unixODBC-2.3.0
pkg_delete: package 'unixODBC-2.3.0' is required by these other packages
and may not be deinstalled:
ekiga3-3.2.6_5
gnome2-2.30.1_1
opal3-3.6.6_6
ptlib-2.6.5_2
```

Okay, let's play Sherlock Holmes and read the Makefile of the ports.

We can safely ignore gnome2, as it's a metaport. The result give us ekiga3 depends of opal3, which depends of ptlib.


```
cd /usr/ports/devel/ptlib
make config
```
grrr no option to disable odbc (but it's always valuable to try).

Let's read the Makefile. Er... there is a --disable-odbc enabled. Something is wrong, oh it conflicts with ptlib26, it's one of those multiversions ports!

Bye ptlib, a ls ../ptlib* tells us the correct package name is devel/ptlib26. Let's retry make config. Oh! An option to disable ODBC support.

(3) We need to apply the solution/fix/workaround/kludge found:


```
cd /usr/ports/devel/ptlib26
make deinstall clean
make config #and we disable Use ODBC this time
make reinstall clean
```


```
cd /usr/ports/devel/ptlib26
make deinstall clean
make config #and we disable Use ODBC this time
make reinstall clean
```

And let's deinstall unixodbc:


```
scherzo# cd /usr/ports/databases/unixODBC
scherzo# make deinstall
===>  Deinstalling for databases/unixODBC
===>   Deinstalling unixODBC-2.3.0
pkg_delete: package 'unixODBC-2.3.0' is required by these other packages
and may not be deinstalled (but I'll delete it anyway):
ekiga3-3.2.6_5
gnome2-2.30.1_1
opal3-3.6.6_6
```

(4) Cleans the mess

So this time, ptlib dependency have disappeared and unixODBC is deinstalled.

A (now erroneous) dependency still exists between ports built against ptlib.

To fix that, there is a tool called ''pkgdb''. Invoke it with the -F (short for --fix) options:


```
scherzo# pkgdb -F
--->  Checking the package registry database
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 808 packages found (         -2 +41) (...)......................................... done]
Stale dependency: ekiga3-3.2.6_5 -> unixODBC-2.3.0 (databases/unixODBC):
-> Deleted. (irrelevant)
Stale dependency: gnome2-2.30.1_1 -> unixODBC-2.3.0 (databases/unixODBC):
-> Deleted. (irrelevant)
Stale dependency: opal3-3.6.6_6 -> unixODBC-2.3.0 (databases/unixODBC):
-> Deleted. (irrelevant)
```

Hop, it have cleaned our dependencies automatically.

We can now resume our KDE compilation. It should resume with the libiodbc installation.


----------



## dheerajsuthar (Jun 21, 2010)

Thanks will try that on my system.I really appreciate you kind detailed reply.


----------



## tegaP0PwkubtXdsK (Jul 2, 2010)

Dereckson said:
			
		

> (1) We need a general understanding of the problem. A google search on unixodbc and libiodbc explains its two drivers doing the same job, on a rather compatible way.
> 
> (2) We need a local understanding of the problem, ie here "what port uses this unixODBC?". To get the answer, *pkg_delete unixODBC-2.3.0* (pkg_delete won't delete anything used by other packages). It gives a list of the packages using the library.



Awesome post, thank you!

Chris


----------



## hedgehog (Jul 3, 2010)

Dereckson said:
			
		

> (2) We need a local understanding of the problem, ie here "what port uses this unixODBC?". To get the answer, *pkg_delete unixODBC-2.3.0* (pkg_delete won't delete anything used by other packages). It gives a list of the packages using the library.


i think there is much better way to get such info without a risk of removing package :]

```
$ man pkg_info | egrep -A 1 '\-R'
     -R      For each of the specified packages, show the list of installed
             packages which require it.
```

`[b]pkg_info -R unixODBC-2.3.0[/b]`


----------



## ikbendeman (Oct 6, 2010)

I don't think ekiga will build correctly without unixODBC, which is a problem since it's part of x11/gnome2. How hard would it be to configure devel/ptlib26 to build against databases/libiodbc instead of databases/unixODBC? I mean, they're supposed to be compatible from what I understand...


----------



## ikbendeman (Oct 6, 2010)

I got it to work! I edited /usr/local/ports/devel/ptlib26/Makefile and changed the following section:


```
line 53 | .if defined(WITH_ODBC)
line 54 | CONFIGURE_ARGS+=     --enable-odbc
line 55 | LIB_DEPENDS+=        odbc.1:${PORTSDIR}/databases/unixODBC
line 56 | .esle
line 57 | CONFIGURE_ARGS+=     --disable-odbc
```

to the following:


```
line 53 | .if defined(WITH_ODBC)
line 54 | CONFIGURE_ARGS+=     --enable-odbc
line 55 | LIB_DEPENDS+=        iodbc.3:${PORTSDIR}/databases/libiodbc
line 56 | .else
line 57 | CONFIGURE_ARGS+=     --disable-odbc
line 58 | .endif
```


----------



## BostonDriver (Dec 12, 2010)

Any idea how to solve for a "package only" based system?

/usr/ports doesn't even exist on this machine.  I'd like to keep it this way until time permits to upgrade to stable.

In my case, I have kde4 installed first, now I'm trying to get gnome2 installed.  I'm on a fresh 8.1-Release system (amd64), installed from dvd iso found via FreeBSD torrents.

I'm only using e.g. `pkg_add -r gnome2` (as there are a few people who want to use gnome instead of kde4.)


----------



## wblock@ (Dec 12, 2010)

BostonDriver said:
			
		

> Any idea how to solve for a "package only" based system?



Make the modifications on a system with ports and build a package...  The net result of packages is that you can't change them, they're binaries.



> /usr/ports doesn't even exist on this machine.  I'd like to keep it this way until time permits to upgrade to stable.



Ports and the OS are not tied together, and as long as you don't change major versions of the OS, your installed applications will continue to work.  So you can run newer ports without upgrading to -stable, or upgrade to -stable and continue to run your existing applications.


----------



## BostonDriver (Dec 12, 2010)

wblock said:
			
		

> Make the modifications on a system with ports and build a package...  The net result of packages is that you can't change them, they're binaries.



The only system I have with ports is FreeBSD 4.10-Stable.

As binaries, I'd (foolishly) expected the packages for -Release to just work together and keep out of each others way.

If I had time, I'd just make 'em all via portupgrade.... I don't have time right now.  This is also my first 64bit machine (at home anyway) so any packages I built from ports on one of the other 32bit systems would only be 32bit.  I hoped the 64bit versions were pre-built, it would same me the effort until time permits and/or I really needed "make config" to change things to my specific needs.

I guess for now, the gnome users are stuck with kde or just a shell lol

Thanks for your suggestion


----------



## Dereckson (Dec 13, 2010)

(i) Compilation isn't so problematic : you can use another desktop environment during the few hours to 3 days needed to compile all, your system stays responsive, there are still free RAM.

(ii) Fresh FreeBSD install + pkg_add -r gnome2 just works, the problem in this topic only concerns dual KDE/Gnome installations.

(iii) You can start the install from packages, then compile the problematic port, then resume the install from packages. So you'll only have ONE port and its dependencies not yet installed through packages to compile. I'll be happy to assist you in the process.

(iv) You can put the ports where you want: /home/bostondriver/ports, /tmp/ports are maybe some interesting locations outside your /usr partition.

(v) You can use and upgrade -STABLE with a /usr/ports folder, freebsd-update doesn't touch this folder.


----------



## BostonDriver (Dec 13, 2010)

Dereckson said:
			
		

> (ii) Fresh FreeBSD install + pkg_add -r gnome2 just works, the problem in this topic only concerns dual KDE/Gnome installations.



Understood.  pkg_add -r kde4 went flawlessly.  Adding gnome2 (or trying to) a day or two later hit the issue.

I actually added kde4 via sysinstall.  I hit this gnome2/kde4 co-exist problem when also trying to use sysinstall.  My attempt to add gnome2 came after the install install of kde and after some people complained that kde (via tightvnc) wasn't "working" as they are used to.  (This is something I'm looking into, but out of scope of this thread.)  So gnome was installed, or I tried to.

Since prior posts, I used pkg_add -r gnome2 (not sysinstall) to see what happens.  The problem in this thread still exists, but at least pkg_add didn't stop.  "Enough" of gnome2 exists where gnome can be used (and does behave a lot better under vnc than kde.)

We also have FreeBSD 8.1 running as a KVM guest, and there kde4 via tightvnc is awful!  (Other vnc packages will be tried shortly.)  Moving to gnome2 works far better, and users want to standardize on one, so I need gnome on this machine... at least until I can get kde to behave.


----------



## ikbendeman (Sep 18, 2013)

*2013, still here....*

It looks like this is still a problem. My fix posted above still works... how do I contact the port maintainer and get them to fix this? libiodbc works just fine in place of unixODBC (I hear that unixODBC _may_ work in place of libiodbc). Anyways, they both implement the same ABI but since I haven't yet learned SQL, I've yet to use either library while writing any of my own software.


----------



## wblock@ (Sep 18, 2013)

A port's maintainer can be found with the maintainer target:

```
# cd /usr/ports/databases/unixODBC
# make maintainer
```

For that port, maintainer is ports@, meaning there is no specific maintainer.

It is usually preferable to enter a PR so the problem can be tracked.


----------

