Error updating Exim from 4.96.1-7-g79877b70e to 4.97

I have some something similar when going from exim 4.96.2 to 4.97 on AlmaLinux:
rfc2047.o: In function `rfc2047_decode2':
rfc2047.c:(.text+0x3ec): undefined reference to `libiconv_open'
rfc2047.c:(.text+0x4da): undefined reference to `libiconv'
rfc2047.c:(.text+0x568): undefined reference to `libiconv_close'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:688: exim] Error 1
make[1]: Leaving directory '/usr/local/directadmin/custombuild/tmp/tmp.nJtwWcQgnG.exim-4.97.tar.gz/build-Linux-x86_64'
make: *** [Makefile:37: all] Error 2
doExim: failed to compile '/usr/local/directadmin/custombuild/cache/exim-4.97.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.nJtwWcQgnG.exim-4.97.tar.gz'
failed to compile exim 4.97

Additionally, the update from PHP 8.1.24 to 8.1.25 fails.

I didn't change anything from the original settings and didn't add any software. Any idea what causes this? Should I somehow add libiconv?
 
Hello,
I have smiler problem.

when I am updating Apache and Exim , I am getting this error. How can i fix this problem
Thnx
-----
/usr/local/directadmin/custombuild/httpd-2.4.58/srclib/apr/libtool --silent --mode=link gcc -std=gnu11 -pthread -I/usr/local/include \
-L/usr/local/lib -o ab ab.lo -lz -lsystemd /usr/local/directadmin/custombuild/httpd-2.4.58/srclib/apr-util/libaprutil-1.la -lexpat -liconv /usr/local/directadmin/custombuild/httpd-2.4.58/srclib/apr/libapr-1.la -lrt -lcrypt -lpthread -ldl -lm -lssl -lcrypto -lrt -lcrypt -lpthread -ldl
/usr/bin/ld: warning: libkeyutils.so.1, needed by //usr/lib64/libgssapi_krb5.so.2, not found (try using -rpath or -rpath-link)
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_read_alloc@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_set_timeout@KEYUTILS_1.0'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_unlink@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_get_keyring_ID@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_get_persistent@KEYUTILS_1.5'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_link@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_describe_alloc@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_search@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `add_key@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_clear@KEYUTILS_0.3'
collect2: error: ld returned 1 exit status
make[2]: *** [ab] Error 1
make[2]: Leaving directory `/usr/local/directadmin/custombuild/httpd-2.4.58/support'
make[1]: Leaving directory `/usr/local/directadmin/custombuild/httpd-2.4.58/support'
*** The make has failed. Exiting...
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
 
Has anyone encountered any issues when running commands, and subsequently, Apache fails to start?

I faced issues with Exim installation on three servers, and following advice from this forum, I executed the following commands:

Code: 
da build list_removals
da build remove_items
da build remove_old_local libiconv
da build all

After completion, Exim was installed correctly, but Apache stopped starting, displaying the following error:

Syntax error on line 50 of /etc/httpd/conf/httpd.conf: Syntax error on line 4 of /etc/httpd/conf/extra/httpd-phpmodules.conf: Syntax error on line 2 of /etc/httpd/conf/extra/httpd-modsecurity.conf: Cannot load /usr/lib/apache/mod_security2.so into the server: /usr/lib/apache/mod_security2.so: undefined symbol: lua_setglobal

I had a similar issue earlier this year, and following the thread I had previously responded to (where the problem was resolved - https://forum.directadmin.com/threads/urgent-apache-down-on-multiple-servers.65960/), I ran the commands again:

Code: 
rm -f /usr/local/include/lua*
rm -f /usr/local/lib/liblua*
rm -f /usr/local/lib/lua*
rm -rf /usr/local/lib/lua
/usr/local/directadmin/custombuild/build modsecurity

This time, Apache did not resume functioning after, requiring the uninstallation of ModSecurity. Any suggestions on what might be happening?
 
We got reports with apache failing to start if modsecurity is used and it is linked against old custom lua library in /usr/local.

Next DA version 1.657 (in alpha release channel right now) already have custom lua detection and removal scripts. It will be reported as other old libraries with the da build list_removals command.

I would not advise moving it manually, because it is hard to catch all the files used by lua. Commands in @paulonichio are NOT correct and will only partially remove lua (it leaves /usr/local/include/lauxlib.h not removed). It will cause more problems having library partially removed.

I would recommend either jumping to alpha release channel and removing lua with DA commands:
  • da update alpha - update to alpha release
  • da build list_removals - check if new old libraries are detected and eligible for removal
  • da build remove_old_local lua - remove old local lua library
  • da update - jump back to the latest version of your preferred release channel (configured in directadmin.conf).
Alternatively lua can be removed manually with command:

Code: 
rm -rf /usr/local/lib/liblua*
rm -rf /usr/local/lib/lua
rm -rf /usr/local/include/{lua.h,luaconf.h,lualib.h,lauxlib.h,lua.hpp}
rm -rf /usr/local/bin/{lua,luac}
rm -rf /usr/local/man/man1/{lua.1,luac.1}
rm -rf /usr/local/share/lua
 
fln said:
We got reports with apache failing to start if modsecurity is used and it is linked against old custom lua library in /usr/local.

Next DA version 1.657 (in alpha release channel right now) already have custom lua detection and removal scripts. It will be reported as other old libraries with the da build list_removals command.

I would not advise moving it manually, because it is hard to catch all the files used by lua. Commands in @paulonichio are NOT correct and will only partially remove lua (it leaves /usr/local/include/lauxlib.h not removed). It will cause more problems having library partially removed.

I would recommend either jumping to alpha release channel and removing lua with DA commands:
  • da update alpha - update to alpha release
  • da build list_removals - check if new old libraries are detected and eligible for removal
  • da build remove_old_local lua - remove old local lua library
  • da update - jump back to the latest version of your preferred release channel (configured in directadmin.conf).
Alternatively lua can be removed manually with command:

Code: 
rm -rf /usr/local/lib/liblua*
rm -rf /usr/local/lib/lua
rm -rf /usr/local/include/{lua.h,luaconf.h,lualib.h,lauxlib.h,lua.hpp}
rm -rf /usr/local/bin/{lua,luac}
rm -rf /usr/local/man/man1/{lua.1,luac.1}
rm -rf /usr/local/share/lua
Click to expand...
it didn't fix the problem.
Also I have another problem when updating Exim, which I think is due to the same issue..

cc xclient.c
cc version.c
cc -o exim
/usr/bin/ld: warning: libkeyutils.so.1, needed by //usr/lib64/libgssapi_krb5.so.2, not found (try using -rpath or -rpath-link)
rfc2047.o: In function `rfc2047_decode2':
rfc2047.c:(.text+0x49f): undefined reference to `libiconv_open'
rfc2047.c:(.text+0x543): undefined reference to `libiconv'
rfc2047.c:(.text+0x5f2): undefined reference to `libiconv_close'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_read_alloc@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_set_timeout@KEYUTILS_1.0'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_unlink@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_get_keyring_ID@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_get_persistent@KEYUTILS_1.5'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_link@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_describe_alloc@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_search@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `add_key@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_clear@KEYUTILS_0.3'
collect2: error: ld returned 1 exit status
make[1]: Leaving directory `/usr/local/directadmin/custombuild/tmp/tmp.w0TZ2TRZyC.exim-4.97.tar.gz/build-Linux-x86_64'
make[1]: *** [exim] Error 1
make: *** [all] Error 2
doExim: failed to compile '/usr/local/directadmin/custombuild/cache/exim-4.97.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.w0TZ2TRZyC.exim-4.97.tar.gz'
failed to compile exim 4.97
 
@huseyinktk please open a support ticket regarding this issue.

I have not seen errors or reports related to libkrb5.so before. If I had to guess I would say it is caused by - some old libraries still present on the system or CB customizations or non standard packages being installed on the system.
 
Active8 said:
did you do this ? (backup first)

Code: 
da build list_removals
da build remove_items
da build remove_old_local libiconv
da build all

if you need iconv install it manual
Code: 
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
Click to expand...
After performing your sets of commands, I got a host of errors. It appears it was still using the cached .tar.gz, so after I performed the following commands:
Code: 
cd /usr/local/directadmin/custombuild
./build clean
./build update
./build versions
./build update_versions
I still got the exact same error as before, except that now my PHP 7.4 and 8.0 are no longer working, for some reason it deleted those as well even though they were active PHP versions.
Code: 
/usr/local/php74/sbin/php-fpm74: error while loading shared libraries: libwebp.so.7: cannot open shared object file: No such file or directory
/usr/local/php80/sbin/php-fpm80: error while loading shared libraries: libwebp.so.7: cannot open shared object file: No such file or directory
I had to perform the following actions to get it to work again:
For PHP 7.4, I had to restore both libsodium and libiconv. After that, the following error showed up after trying to build PHP 7.4 again
Code: 
/usr/local/directadmin/custombuild/tmp/tmp.SypiHcQnAM.php-7.4.33.tar.gz/ext/iconv/iconv.c:1007: undefined reference to `libiconv'
Why does it try to refer to a folder or file that doesn't exist?
Code: 
# ls -al /usr/local/directadmin/custombuild/tmp/
total 69880
drwxr-xr-x  2 root root     4096 Nov 28 13:44 .
drwx------. 9 root root     8192 Nov 28 13:44 ..
-rw-r--r--  1 root root  5815883 Nov 28 11:59 usr_local_freetype_backup.tar.gz
-rw-r--r--  1 root root 35766324 Nov 28 11:59 usr_local_icu_backup.tar.gz
-rw-r--r--  1 root root  2810121 Nov 28 12:00 usr_local_libiconv_backup.tar.gz
-rw-r--r--  1 root root  1688169 Nov 28 11:59 usr_local_libjpeg_backup.tar.gz
-rw-r--r--  1 root root    41627 Nov 28 11:59 usr_local_libltdl_backup.tar.gz
-rw-r--r--  1 root root    97909 Nov 28 11:59 usr_local_libmcrypt_backup.tar.gz
-rw-r--r--  1 root root   366746 Nov 28 11:59 usr_local_libmhash_backup.tar.gz
-rw-r--r--  1 root root  1195349 Nov 28 11:59 usr_local_libpcre_backup.tar.gz
-rw-r--r--  1 root root  2251075 Nov 28 11:59 usr_local_libpng_backup.tar.gz
-rw-r--r--  1 root root  2410457 Nov 28 11:59 usr_local_libsodium_backup.tar.gz
-rw-r--r--  1 root root    79173 Nov 28 11:59 usr_local_libsrs_alt_backup.tar.gz
-rw-r--r--  1 root root  2766643 Nov 28 11:59 usr_local_libwebp_backup.tar.gz
-rw-r--r--  1 root root 12975056 Nov 28 11:59 usr_local_libxml2_backup.tar.gz
-rw-r--r--  1 root root  3113621 Nov 28 11:59 usr_local_libxslt_backup.tar.gz
-rw-r--r--  1 root root   127584 Nov 28 11:59 usr_local_libzip_backup.tar.gz
I had to restore every single one of them, then build the PHP versions, and everything is finally working at this moment.
I was not expecting this extreme system instability. @Richard G
 
patrickkasie said:
I was not expecting this extreme system instability. @Richard G
Click to expand...
Neither do I and as far as I've seen almost nobody had this issue in this extreme way.
So I would tend to say that it most likely is/was caused by some customisation somewhere. It is the iconv issue as far as I can see.

Only 1 person I've seen now on the forums also having issues in spite of running the suggested commands, and he was advised to send in a ticket to investigate why the commands given by @fln were not working.
Maybe he can explain or help you with this issue, or see what is causing this problem for you.
 
@patrickkasie in DA 1.657 nothing was changes regarding this (except DA now detects a couple more old libraries). Removing old libraries from /usr/local and rebuilding software components should solve the issue. If it does not - please open a support ticket.
 
It was a bit of a mess for me, I was just running the regular build update, update_versions. But then PHP wouldn't compile because of iconv. Then I ran the remove_items stuff. But then Exim also wouldn't compile. I had to enable the epel repo as mentioned in this topic. Then I had to install package perl-File-FcntlLock because it gave error Can't locate File/FcntlLock.pm (on AlmaLinux 8).

Edit: Imagic was also giving issues in PHP, but you will only notice this in the website itself.
I ran this to fix.
da build imagemagick
da build php_imagick
 
Last edited:
It seems every directadmin system will need a manual update to remove these iconv files in order to continue updating things like exim and php - which is a lot of servers. The build all also on cloudlinux systems will have php show 503 errors until rebuilt (taking a long time), plus the addition of many da rewrite_confs and cagefs updates the process per server can be extremely long. There really should be other considerations here to prevent this type of manual intervention on all servers.
 
I've the same problem with all servers

on exim update:
rfc2047.c:(.text+0x49f): undefined reference to `libiconv_open'
rfc2047.c:(.text+0x543): undefined reference to `libiconv'
rfc2047.c:(.text+0x5f2): undefined reference to `libiconv_close'
collect2: error: ld returned 1 exit status
make[1]: *** [exim] Error 1
make[1]: Leaving directory `/usr/local/directadmin/custombuild/tmp/tmp.l3IU5IH72Q.exim-4.97.tar.gz/build-Linux-x86_64'
make: *** [all] Error 2
doExim: failed to compile '/usr/local/directadmin/custombuild/cache/exim-4.97.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.l3IU5IH72Q.exim-4.97.tar.gz'
failed to compile exim 4.97
Click to expand...

on php 8.1/8.2 update:
configure: error: iconv does not support errno
doPhp_build: failed to compile '/usr/local/directadmin/custombuild/cache/php-8.1.26.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.zEZkr7GIbZ.php-8.1.26.tar.gz'
Click to expand...

OS: CentOS 7

Update:

And after running commands
da build list_removals
da build remove_items
da build remove_old_local libiconv
da build all
Click to expand...

I've no any php version on the server :( ,
getting new error:
configure: error: xml2-config not found. Please check your libxml2 installation.
Click to expand...

after installing it with
yum install libxml2-devel libxml2
Click to expand...

again getting another error:
configure: error: mcrypt.h not found. Please reinstall libmcrypt.
Click to expand...
then
configure: error: xslt-config not found. Please reinstall the libxslt >= 1.1.0 distribution
Click to expand...

and despite that, I've reinstalled with command:
sudo yum install libxslt
Click to expand...

still have the same last error

and for php8.1
configure: error: Package requirements (libwebp >= 0.2.0) were not met:

No package 'libwebp' found
Click to expand...

despite that I've it
# rpm -qi libwebp
Name : libwebp
Version : 0.3.0
Release : 11.el7
Architecture: x86_64
Click to expand...

?‍♂️

Solution:
So I had to reinstall the next packages to make PHP 7.4/8.1 up and running:
yum install libxml2-devel libxml2 libmcrypt libmcrypt-devel libxslt libxslt-devel libwebp libwebp-devel libsodium libsodium-devel icu icu-devel -y
Click to expand...

but unable to install PHP 5.6
make: *** [ext/intl/intl_convertcpp.lo] Error 1
make: *** Waiting for unfinished jobs....
doPhp_build: failed to compile '/usr/local/directadmin/custombuild/cache/php-5.6.40.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.dtKJ1B0dsB.php-5.6.40.tar.gz'
Click to expand...

Any ideas how to solve the problem?
 
Last edited:
Hi,

Same problem. For my part, I created a thread about this:

configure: error: GD build test failed PHP 8.1 fastcgi

Hello, When trying to compile PHP 8.1 in fastcgi on a CloudLinux release 7.9 we get the following error that I have attached. cat /etc/redhat-release CloudLinux release 7.9 (Boris Yegorov) # PHP Settings php1_release=8.1 php1_mode=fastcgi We do not use any custom, so you must use the...
forum.directadmin.com forum.directadmin.com

In my case I was able to solve it first by executing:

cd directadmin/custombuild
da build list_removals
da build remove_items
da build remove_old_local libiconv
da build all

And for the php problem in the thread above I responded indicating the solution that worked for me. Just reinstall the libraries again before compiling php again

Kind regards
 

Attachments

This "fix" is a terrible option. Forcing a recompile of everything, with out an improve rewrite_confs - does not work in an environment with more than a few users. I get the test is probably 1 user and one domain, but anyone with say 100+ users has a 1 hour recompile, add in cloudlinux its 2+ hours. This is not something I expect of a 20 year old production ready control panel. This forces downtime on every server that needs to remove these libraries.
 
  • Like
Reactions: GR_
We're having the same issues on a lot of our servers. It might be the case that we can "fix it" by doing the all the removing, compiling twice, installing libraries again etc. etc. But we have like 200 servers, and don't just trust to do it all automatically..
Please fix this like it should. So a normal update would just work... This feels untested and "just try this, it might work" instead of a fix, and I can't risk doing this on my entire platform.

Running CentOS 7 and Cloudlinux 8 (my CL8 servers look like they are updating fine so far)
 
Hi all,

I've been busy with non-virtual life so I'm kinda late to the party...

Started out with the same exim update issues as the thread starter. Went ahead to remove old libraries:

da update alpha
da build list_removals
da build remove_items
da update

Liviconv I had to remove manually (as was told by the removal script):
da build remove_old_local libiconv
da build all

The good news is that exim has updated just fine now.
The bad news is that php8 and nginx are broken now, and all my websites are down.

When trying to update php8 I get this:

Code: 
checking for sodium support... yes
checking for libsodium >= 1.0.8... no
configure: error: Package requirements (libsodium >= 1.0.8) were not met:


No package 'libsodium' found


Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.


Alternatively, you may set the environment variables LIBSODIUM_CFLAGS
and LIBSODIUM_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
doPhp_build: failed to compile '/usr/local/directadmin/custombuild/cache/php-8.0.30.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.W8WQ7X6eSx.php-8.0.30.tar.gz'

Also, custombuild reports current PHP 8.0 version as "missing".

When trying to update nginx, I get this:

Code: 
configuring additional modules
adding module in ../modsecurity-nginx-v1.0.3
checking for ModSecurity library ... not found
checking for ModSecurity library in /usr/local/modsecurity ... not found
 ./configure: error: ngx_http_modsecurity_module requires the ModSecurity library.


*** There was an error while trying to configure Nginx. Check the  file
2024/01/18 10:46:18  info executing task task=action=notify&message=CustomBuild+installation+has+failed%2C+please+check+the+following+file+for+more+information%3A%0A%2Fvar%2Flog%2Fdirectadmin%2Fcustombuild.1705571054.21317.YWxsAA.log&subject=CustomBuild+installation+has+failed&value=admin

Obviously, I could try and re-add ModSecurity now and try and fiddle with libsodium, but I'm not sure if that'll catch all the problems, so I was wondering if there's a better, more general fix for these issues. Server is running CentOS 7. Thanks in advance.
 
Last edited:
Fixed this now by doing/running the following:

da build modsecurity
da build nginx_apache

Reinstalling libsodium didn't fix the php problem, so I ended up dragging usr_local_libsodium_backup.tar.gz back to /usr/local and untarring it.

I then updated php8 via custombuild and now everything seems to be up and running again.

(Very glad though I only have one server.)
 
Hello everyone. Just adding a comment that we just ran across this problem when trying to update Exim and PHP. The fix looks very daunting in terms of find a wide enough maintenance window. Our installation is pretty much blog standard and dates back about 3 years. It was however seeded from a cPanel migration. I hope the DA folks can provide a clean fix to this difficulty as doing all the rebuilds seems like poor fix to what is likely a pervasive problem. I'll keep an eye on this thread.
 
You must log in or register to reply here.
Back
Top