# libiconv.so not found, but it's there



## spork (May 25, 2015)

I'm working on a long-neglected 8.4 box (inside a jail) with a ports tree from yesterday.

I seem to be in a loop where `php5.4` is looking for `gettext`, `gettext` is looking for `libiconv`, mistakenly thinking `libiconv` is not already installed and then the whole thing falls over when `portmaster` tries to install `libiconv`.

The root of the problem seems to be this:


```
gettext-runtime-0.19.4 depends on shared library: libiconv.so - not found
```

Even though:

```
[root@nac /usr/ports/devel/gettext-runtime]#  ls -l /usr/local/lib/libiconv.*
-rw-r--r--  1 root  wheel  1056112 May 24 23:44 /usr/local/lib/libiconv.a
lrwxr-xr-x  1 root  wheel       17 May 24 23:44 /usr/local/lib/libiconv.so -> libiconv.so.2.5.1
lrwxr-xr-x  1 root  wheel       17 May 24 23:44 /usr/local/lib/libiconv.so.2 -> libiconv.so.2.5.1
-rw-r--r--  1 root  wheel  1057233 May 24 23:44 /usr/local/lib/libiconv.so.2.5.1
lrwxr-xr-x  1 root  wheel       13 May 24 23:44 /usr/local/lib/libiconv.so.3 -> libiconv.so.2
[root@nac /usr/ports/devel/gettext-runtime]#
```

Stepping outside of `portmaster` and manually installing `libiconv` and `gettext-runtime` does not seem to help, `portmaster` still wants to reinstall things that are already up to date:


```
==>>> lang/php5 1/19 >> libxml2-2.9.1_1 >> gmake-3.82_1 >> gettext-runtime-0.19.4 (3/42)

===>>> Currently installed version: gettext-runtime-0.19.4
===>>> Port directory: /usr/ports/devel/gettext-runtime

===>>> Starting check for build dependencies
===>>> Gathering dependency list for devel/gettext-runtime from ports
===>>> Dependency check complete for devel/gettext-runtime

===>>> lang/php5 1/19 >> libxml2-2.9.1_1 >> gmake-3.82_1 >> gettext-runtime-0.19.4 (3/42)

===>  Cleaning for gettext-runtime-0.19.4
```


----------



## wblock@ (May 25, 2015)

Might you have missed /usr/ports/UPDATING entry 20141130?


----------



## spork (May 25, 2015)

I manually dealt with that after the first few failures:

```
[root@nac /usr/ports/devel/gettext-tools]# pkg info |grep gettext
gettext-runtime-0.19.4         GNU gettext runtime libraries and programs
gettext-tools-0.19.4           GNU gettext development and translation tools
p5-Locale-gettext-1.05_3       Message handling functions
php5-gettext-5.4.29            The gettext shared extension for php
```


----------



## kpa (May 25, 2015)

Try running `pkg check -aBds` as root.


----------



## spork (May 25, 2015)

That returned some info on `net-snmp` missing `libpkg.so.1`.

Something seems pretty fundamentally jacked-up in this jail though.  Leaving `portmaster` behind, I see another instance of the check for a shared library not being accurate:


```
[root@nac /usr/ports/lang/php5]# make clean
===>  Cleaning for php5-5.4.41
[root@nac /usr/ports/lang/php5]# make
===>  License PHP301 accepted by the user
===>  Found saved configuration for php5-5.4.29
===>   php5-5.4.41 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by php5-5.4.41 for building
===>  Extracting for php5-5.4.41
=> SHA256 Checksum OK for php-5.4.41.tar.bz2.
=> SHA256 Checksum OK for php-5.4.x-mail-header.patch.
===>  Patching for php5-5.4.41
===>  Applying distribution patches for php5-5.4.41
===>  Applying FreeBSD patches for php5-5.4.41
===>   php5-5.4.41 depends on file: /usr/local/bin/autoconf-2.69 - found
===>   php5-5.4.41 depends on shared library: libpcre.so - not found  <<<<<=======  NOTE
```

Again, checking it out, libpcre.so and the destination of the symlink do exist:


```
[root@nac /usr/ports/lang/php5]# ls -la /usr/local/lib/libpcre.so*
lrwxr-xr-x  1 root  wheel      16 May 25 12:16 /usr/local/lib/libpcre.so -> libpcre.so.1.2.5
lrwxr-xr-x  1 root  wheel      16 May 25 12:16 /usr/local/lib/libpcre.so.1 -> libpcre.so.1.2.5
-rwxr-xr-x  1 root  wheel  467889 May 25 12:16 /usr/local/lib/libpcre.so.1.2.5
lrwxr-xr-x  1 root  wheel      12 May 25 12:16 /usr/local/lib/libpcre.so.3 -> libpcre.so.1
[root@nac /usr/ports/lang/php5]#
```


----------



## kpa (May 25, 2015)

How is the jail startup defined in /etc/jail.conf or /etc/rc.conf (if you use that instead)? You might need to run `/etc/rc.d/ldconfig start` in the jail once if you're not using the typical exec.start = "/bin/sh /etc/rc"; as the startup command for the jail.


----------



## spork (May 25, 2015)

I use ezjail, which should of course be running normal /etc/rc.d/ldconfig on startup.

Right now I'm brute-forcing this by adding "FORCE_PKG_REGISTER".  That's working so far, but it's kind of ugly.

On the ldconfig issue, here's what I'm seeing for pcre:


```
root@nac:~ # ldconfig -r | grep pcre
    206:-lpcre32.0 => /usr/local/lib/libpcre32.so.0
    207:-lpcrecpp.0 => /usr/local/lib/libpcrecpp.so.0
    224:-lpcre.3 => /usr/local/lib/libpcre.so.3
    225:-lpcre16.0 => /usr/local/lib/libpcre16.so.0
    279:-lpcre.1 => /usr/local/lib/libpcre.so.1
    317:-lpcreposix.0 => /usr/local/lib/libpcreposix.so.0
    329:-lpcre.0 => /usr/local/lib/compat/pkg/libpcre.so.0
    368:-lpcre16.2 => /usr/local/lib/compat/pkg/libpcre16.so.2
root@nac:~ #
```


----------



## h0lly (Jun 10, 2015)

spork said:


> I'm working on a long-neglected 8.4 box (inside a jail) with a ports tree from yesterday.
> 
> I seem to be in a loop where php5.4 is looking for gettext, gettext is looking for libiconv, mistakenly thinking libiconv is not already installed and then the whole thing falls over when portmaster tries to install libiconv.
> 
> ...



`rm /usr/share/misc/magic.mime.mgc`


----------



## spomerg (Jul 6, 2015)

h0lly said:


> `rm /usr/share/misc/magic.mime.mgc`



h0lly, why does this work?

I too somehow ended up in "ports hell" (been a while) on my test server where I had about 6 ports that wouldn't update with portupgrade or portmaster because they had missing library dependencies, including libiconv.so, even though the libraries were clearly in /usr/local/lib. I moved magic.mime.mgc to another directory (in case I actually did need it) and all my ports could be upgraded after that. What is this file for? Doesn't seem like it would have anything to do with the dependency issues. I noticed this file wasn't on any of my other FreeBSD servers.

- Gavin


----------

