build / update exim show error

[fln]

Thanks for the feedback.

In the current state CB works perfectly fine on clean systems (which does not have custom libraries in /usr/local), making it hard to reproduce such problems on a freshly installed system. However if the system is not clean it seems there are circular dependencies.

We are working on updates to the CB to avoid using locally installed libraries in a more reliable way.

 

[Active8]

it hard to reproduce such problems on a freshly installed system.

That is correct: new installed servers which did not use ./build iconv working flawless, its the older installs which had used this build runs in trouble now, maybe its good to find a old box which build with ./build iconv

We are working on updates to the CB to avoid using locally installed libraries in a more reliable way.

Really appreciated

 

[fln]

A new version of CustomBuild is available in the alpha release channel. This version avoids using customized iconv and icu libraries when building PHP.

With this change doing rm -f /usr/local/include/{libcharset.h,localcharset.h,iconv.h} should allow building both exim and PHP successfully. Any feedback from systems still having those old libs would be really appreciated. It can be tested out with:

rm -f /usr/local/include/{libcharset.h,localcharset.h,iconv.h}
da config-set update_channel alpha
da update
da build exim
da build php

Note: header files still needs to be manually removed.

 

[Ohm J]

I'm afraid, on Rhel OS(7,8,9) don't have libiconv package, it come with 3rd party repo "forensics" and libicu can install from epel repo "yum install libicu60"

there have guy on other thread trying to remove iconv completely but breaking everything due missing "libiconv"

libiconv 1.16 unable to remove

Hi I wanted to update PHP8 but was unable because of the old library libiconv 1.16. There are more threads to find on this forum, but none are very clear on how to proceed without downtime. I want to delete libiconv 1.16 and move over to the system provided libiconv library 2.28 I am running...

forum.directadmin.com

 

[fln]

I'm afraid, on Rhel OS(7,8,9) don't have libiconv package, it come with 3rd party repo "forensics" and libicu can install from epel repo "yum install libicu60"

Not true.

On all DA supported systems (actually most modern systems) iconv comes with glibc:

# rpm -qf /usr/include/iconv.h
glibc-headers-2.17-326.el7_9.x86_64

Also CustomBuild takes care of installing libicu-devel (on RHEL based systems) or libicu-dev (on Debian based systems).

 

[webmaster-hub]

A new version of CustomBuild is available in the alpha release channel. This version avoids using customized iconv and icu libraries when building PHP.

With this change doing rm -f /usr/local/include/{libcharset.h,localcharset.h,iconv.h} should allow building both exim and PHP successfully. Any feedback from systems still having those old libs would be really appreciated. It can be tested out with:

Hi,

On a debian server, updated from Debian 9 to 10, 11 and eventually 12, your solution works for exim, but not for php 8.

libtool: link: cannot find the library `/usr/local/lib/libiconv.la' or unhandled argument `/usr/local/lib/libiconv.la'
make: *** [Makefile:314 : sapi/cli/php] Erreur 1
make: *** Attente des tâches non terminées....
libtool: link: cannot find the library `/usr/local/lib/libiconv.la' or unhandled argument `/usr/local/lib/libiconv.la'
make: *** [Makefile:354 : sapi/litespeed/php] Erreur 1
libtool: link: cannot find the library `/usr/local/lib/libiconv.la' or unhandled argument `/usr/local/lib/libiconv.la'
make: *** [Makefile:394 : sapi/cgi/php-cgi] Erreur 1
libtool: link: cannot find the library `/usr/local/lib/libiconv.la' or unhandled argument `/usr/local/lib/libiconv.la'
make: *** [Makefile:326 : sapi/fpm/php-fpm] Erreur 1
libtool: link: cannot find the library `/usr/local/lib/libiconv.la' or unhandled argument `/usr/local/lib/libiconv.la'
make: *** [Makefile:368 : sapi/phpdbg/phpdbg] Erreur 1
grep: /usr/local/lib/libiconv.la: No such file or directory
/usr/bin/sed: can't read /usr/local/lib/libiconv.la: No such file or directory
libtool: link: `/usr/local/lib/libiconv.la' is not a valid libtool archive
make: *** [Makefile:166 : libphp.la] Erreur 1
*** The make has failed. Exiting...

I restored /usr/local/lib/libiconv.* from my backup and got it working for exim and php !

Dan

 

[fln]

@webmaster-hub were you using CustomBuild from alpha branch or current?

 

[webmaster-hub]

From the alpha branch !

*****:root# da version
DirectAdmin v.1.656 1b3eb7f61397923af46a3e3c3cbe36697c1608f3
*****:root# da update
directadmin alpha v1.656 1b3eb7f61397923af46a3e3c3cbe36697c1608f3 linux_amd64: already latest

 

[bertvandepoel]

We ran into this issue on Tuesday and I spent most of that day and the rest of the days after creating a cleanup script. There's a truly huge amount of stuff that DA's custombuild has left around. Even if we don't consider the stuff that doesn't "do" anything, it goes well beyond iconv and icu mentioned by @fln. Specifically, libxml2, pcre and libzip also caused issues for us.

I wrote the script attached to this post to clean up all crap that has been left behind. This script is offered as is without any warranty or guarantee. I'm sharing it to help others. It doesn't come with any promises it won't break anything. What it does is:

• It purges the /usr/local/lib and /usr/local/include folders. If you compiled anything yourself (so outside of custombuild) this is a bad idea so don't run this script if you've been doing compilation yourself.
• It removes a bunch of binaries from iconv, libxml2, libxslt, icu, zstd, libjpg, libpng, libwebp, freetype2, libmcrypt, libspf2, (lib)pcre and (lib)zip from /usr/local/bin
• It removes the leftover nghttp2 folder
• It removes all the docs, man pages and locales those binaries and libraries mentioned above had installed
• It strips any leftovers of a custombuild install of clamav/freshclam (including the units, so if you're using a distro version of clamav this will break that, so you should comment out the everything from that part expect the /usr/local/bin stuff)
• It then runs ldconfig to update the system on all the removed libraries
• doMigrateToSystemCurl to remove any remnants of custombuild curl
• A full rebuild of everything (using da build all d)

I hope this helps some of you get things working again. We tested it on a few servers (in a testing environment) and up until now it's been fine. If anything pops up we will make a new post. Any feedback is also very welcome!

PS: Don't forget to rename the extension to .sh and make it executable with chmod +x. The script presumes you're root (e.g. sudo -s) and that "da build" works as a command.

 

[Richard G]

The script presumes you're root (e.g. sudo -s) and that "da build" works as a command.

Maybe also doublecheck if you might want to change something about removal in the script.
In /usr/local/lib and in /usr/local/include I got a lot of imagemick 7 in there.

In /usr/local/lib/ there is a directory called ioncube on my system (freshly installed Alma 9 server), which contains ioncube_loader_lin_8.1.so and ioncube_loader_lin_8.2.so which would also be removed then.
Those are nowhere to be found anywhere else on the system. So they might be put there by Softaculous or DA ioncube install. I presume these are needed for ioncube to work, right?

I haven't checked the complete script, just had a quick look.

 

[davidc]

With this change doing rm -f /usr/local/include/{libcharset.h,localcharset.h,iconv.h} should allow building both exim and PHP successfully. Any feedback from systems still having those old libs would be really appreciated. It can be tested out with:

Didn't work !!

# build php
...
checking for iconv support... yes
configure: error: Please reinstall the iconv library.

*** There was an error while trying to configure php. Check the configure file

When I check:

# rpm -qf /usr/include/iconv.h
glibc-headers-2.17-326.el7_9.x86_64

How do I get iconv back??

Comment by smtalk in thread "php 8 fails installation"

 

[hugor]

@davidc
In my case it helped to remove /usr/local/bin/iconv as well, in addition to removing the libraries mentioned (/usr/local/include/{libcharset.h,localcharset.h,iconv.h}). Not sure if necessary, but running "sudo ldconfig" would not hurt as well.

 

[pat0]

So again there is serious changes that have not been fully communicated to users and making mess. Manually compiled libraries had many advantages (especially in the case of RedHat systems where curl or openssl from repos are many years behind) but also some disadvantages.

Now as I understand goal is to using libs provided by system repos. But why only libraries and then we manually compile php, apache, etc.? If it was also delivered from system repos, it would make sense.

 

[davidc]

Do you possibly have a custom php configuration file in:

/usr/local/directadmin/custombuild/custom/php

I did, and several had

./configure --with-iconv=/usr/local

and we've seen and been told in this tread to remove "all traces of iconv"

 

[davidc]

Exim compilation problem can be caused by a custom libiconv library installed in /usr/local. A quick check if you have custom libiconv is to see if file /usr/local/include/iconv.h exists.

Removing the custom libiconv library would solve the issue. Following commands would completely remove it from the system:

Doing this will likely cause lots of issues. I ran:

rm -f /usr/local/lib/{libcharset,libiconv}*

and all heck broke loose. An FTP connection reported a php failure and yum is no longer working.

Be careful before following the instructions by fin in this post above

 

[fln]

How do I get iconv back??

You can install custom iconv library back with:

cd /root
wget https://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.17.tar.gz
tar xf libiconv-1.17.tar.gz
cd libiconv-1.17
./configure
make
make install
cd /root
rm -rf libiconv-1.17.tar.gz libiconv-1.17

---

Until we find a clean way to remove the legacy libraries we have released an update for DA 1.655 release - exim will no longer try to use iconv, so everything will be the same as it was before. No need to do anything for the time being.

This is however not a permanent solution, just a way to postpone solving the problem. Having custom libraries and linking other software against is is a real problem that needs to be addressed. Those libraries in /usr/local can get outdated really fast and depending on the distro version you use might be already outdated.

---

But why only libraries and then we manually compile php, apache, etc.? If it was also delivered from system repos, it would make sense.

Of course we could use OS packages for everything but then you would not be able to use multiple versions of PHP or latest Apache like you can now. Our goal is to support a range of core services versions and provide same versions on multiple distributions RHEL 7/8/9, Debian 10/11/12. It is NOT our goal to replace all distro packages with custom ones. Libraries tend to change not as fast as services, so right now CustomBuild provides latest versions of the services used but relies on the distro to provide helper libraries.

For example you might want to run latest PHP without waiting for it to be available on our distro, but you do not really care which version of libpng is being used - the one that is provided with the OS is good enough for any PHP version.

 

[davidc]

Thank you for replying @fin.

I have a mess on my hands now for following your post #4 above.

# yum list installed
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   libiconv.so.2: cannot open shared object file: No such file or directory

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7.5 (default, Jun 20 2023, 11:36:40)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]

and

php: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory

I think the point is that are many things looking for this libiconv.

Wil putting libiconv-1.17 in /root fix this? I have doubts.

David

 

[fln]

I have a mess on my hands now for following your post #4 above.

Yes. I did not expect custom iconv to have been propagated so deeply into the system. This just signifies how important it is to weed it out.

The library itself is minimal and can be easily restored by just compiling a source package.

To reach yum it would mean you are either using custom python that is linked to custom iconv, or one of the auto-loaded python modules is linked against it. It would be great to trace back the path of how it got there.

Could you please share the output of commands:

ldd $(which python)
for lib in /usr/lib64/python*/site-packages/*.so; do tmp=$(ldd $lib 2> /dev/null | grep -F '/usr/local'); if [ -n "$tmp" ]; then echo $lib; echo "$tmp"; fi; done

This should show you all python packages that would use libraries from /usr/local.

 

[davidc]

I think my issue has been partly fixed. I asked the hosting company to restore /usr/local/lib/libiconv

yum is functioning again.

Could you please share the output of commands:

# ldd $(which python)
    linux-vdso.so.1 =>  (0x00007fffa47c0000)
    libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007fb966523000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb966307000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fb966103000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00007fb965f00000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fb965bfe000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fb965830000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fb9668ef000)
[root@vps ~]# for lib in /usr/lib64/python*/site-packages/*.so; do tmp=$(ldd $lib 2> /dev/null | grep -F '/usr/local'); if [ -n "$tmp" ]; then echo $lib; echo $tmp; fi; done
/usr/lib64/python2.7/site-packages/libxml2mod.so
libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x00007fc4377cf000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00007fc435fd6000)
/usr/lib64/python2.7/site-packages/pycurl.so
libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x00007f0492a6c000)
/usr/lib64/python2.7/site-packages/_semanage.so
libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x00007f14c5da0000)
/usr/lib64/python2.7/site-packages/_sqlitecache.so
libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x00007f0dd2f67000) libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x00007f0dd2075000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00007f0dd195d000)

 

[fln]

Thanks!

Seems custom libxml2 liked with custom libiconv replaced system libxml2 library. This gives us hints on how to untangle this mess. Custom libxml2 needs to be removed first.

This helped me to reproduce this web of legacy dependencies.