Solved Error compiling php with UBLOCKCODE????

Richard G

Verified User
Joined
Jul 6, 2008
Messages
13,771
Location
Maastricht
I'm busy helping somebody who had php 5.5 on the vps but updated directadmin so things went starting to do odd.

Now I'm installing php 7.4 with php-fpm and this goes well almost untill the end and then this happens:
Code:
/usr/local/directadmin/custombuild/php-8.0.30/ext/intl/uchar/ublockcode-enum.h: In function 'php_uchar_minit':
/usr/local/directadmin/custombuild/php-8.0.30/ext/intl/uchar/uchar.c:644:57: error: 'UBLOCK_ARABIC_EXTENDED_A' undeclared (first use in this function)
 #define UBLOCKCODE(name) IC_CONSTL("BLOCK_CODE_" #name, UBLOCK_##name)

And more of this ending with:
Code:
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/uchar/uchar.c:743:59: note: in definition of macro 'IC_CONSTL'
  zend_declare_class_constant_long(ce, name, strlen(name), val);
                                                           ^
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/uchar/uother-enum.h:249:1: note: in expansion of macro 'UOTHER'
 UOTHER(LB_REGIONAL_INDICATOR)
 ^
make: *** [ext/intl/uchar/uchar.lo] Error 1
make: *** Waiting for unfinished jobs....
*** The make has failed. Exiting...

I've never seen this one before. How can this be fixed?

@Zhenyapan @jamgames2 or @smtalk any clue?

P.S. Same issue when trying php 8.0.
Edit: Also tried ./build icu but that is not recognized by build.
Icu is installed via yum. OS is Centos 7.9.
 
Last edited:
"UBLOCK_ARABIC_EXTENDED_A" come with ICU49, so it should work fine with ICU50 from OS repo.

I'm not sure it need package "libicu-devel" or not.
Code:
yum install libicu-devel
 
Unfortunately this is also already installed and latest version.

It's a quite plain installation without customisation as far as I can see. It just had php 5.5 before with mod_ruid2. So changed to php 7.4 with php-fpm, should normally compile without any issues.
 
Do you have the directories:

/usr/local/lib
/usr/local/include


on the server? Perhaps there's something from an old ICU in there. Try moving those folders out of the way and recompiling

mv /usr/local/lib /usr/local/lib.old
mv /usr/local/include /usr/local/include.old
 
PHP was complaining before that it was some 48 version and it needed newer.
So I installed icu via yum and then this error message was gone, but now the above notices appear.

I can't just move the /usr/local/lib and /usr/local/include folders as I have compared it with my own Centos 7.9 server and that also has a /usr/local/lib and /usr/local/include folder with a lot of things in there.
See it seems that needs to exist.

However, you were on the right track I think.
I did a "locate libicu" and results are the same on both my server and the problem VPS I'm helping with.

Now on the problem vps only things from the old version are visible in de /usr/local/icu direcotry:
/usr/local/icu/lib/libicudata.so
/usr/local/icu/lib/libicudata.so.48
/usr/local/icu/lib/libicudata.so.48.1.1
/usr/local/icu/lib/libicui18n.so
/usr/local/icu/lib/libicui18n.so.48
/usr/local/icu/lib/libicui18n.so.48.1.1
etc.

On my server that looks like:
/usr/local/icu/lib/libicudata.so
/usr/local/icu/lib/libicudata.so.64
/usr/local/icu/lib/libicudata.so.64.1
/usr/local/icu/lib/libicudata.so.64.2
/usr/local/icu/lib/libicudata.so.65
/usr/local/icu/lib/libicudata.so.65.1
/usr/local/icu/lib/libicudata.so.66
/usr/local/icu/lib/libicudata.so.66.1
and so on.

So I moved the /usr/local/icu to /usr/local/icu.old and then did:
yum reinstall icu icu-devel libicu libicu-devel
which all reinstalled, but the /usr/local/icu directory was not created anymore.

So I tried again and got further, but now this happens on the end of compile.
Code:
pm_stdio.lo sapi/fpm/fpm/fpm_unix.lo sapi/fpm/fpm/fpm_worker_pool.lo sapi/fpm/fpm/zlog.lo sapi/fpm/fpm/events/select.lo sapi/fpm/fpm/events/poll.lo sapi/fpm/fpm/events/epoll.lo sapi/fpm/fpm/events/kqueue.lo sapi/fpm/fpm/events/devpoll.lo sapi/fpm/fpm/events/port.lo sapi/fpm/fpm/fpm_trace.lo sapi/fpm/fpm/fpm_trace_ptrace.lo sapi/fpm/fpm/fpm_systemd.lo -lcrypt -lresolv -lcrypt -lrt -lstdc++ -liconv -lrt -lm -ldl -lsystemd -lxml2 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto -lsqlite3 -lz -lcurl -lxml2 -lssl -lcrypto -lz -lpng16 -lwebp -ljpeg -lfreetype -licuio -licui18n -licuuc -licudata -lonig -lsqlite3 -lxml2 -lxml2 -lsodium -lcrypt -lxml2 -lxml2 -lxml2 -lxslt -lz -liconv -ldl -lm -lxml2 -lexslt -lxslt -lz -liconv -ldl -lm -lxml2 -lzip -lz -lz -lssl -lcrypto -lcrypt   -o sapi/fpm/php-fpm
ext/intl/.libs/php_intl.o: In function `zm_shutdown_intl':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/php_intl.c:1000: undefined reference to `u_cleanup_48'
ext/intl/.libs/php_intl.o: In function `intl_locale_get_default':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/php_intl.c:120: undefined reference to `uloc_getDefault_48'
ext/intl/.libs/php_intl.o: In function `zm_info_intl':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/php_intl.c:1048: undefined reference to `ucal_getTZDataVersion_48'
ext/intl/.libs/intl_error.o: In function `intl_error_get_message':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/intl_error.c:140: undefined reference to `u_errorName_48'
ext/intl/.libs/intl_convert.o: In function `intl_convert_utf8_to_utf16':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/intl_convert.c:70: undefined reference to `u_strFromUTF8_48'
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/intl_convert.c:92: undefined reference to `u_strFromUTF8_48'
ext/intl/.libs/intl_convert.o: In function `intl_convert_utf16_to_utf8':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/intl_convert.c:127: undefined reference to `u_strToUTF8_48'
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/intl_convert.c:141: undefined reference to `u_strToUTF8_48'
ext/intl/collator/.libs/collator_class.o: In function `collator_object_destroy':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/collator/collator_class.c:172: undefined reference to `ucol_close_48'
ext/intl/collator/.libs/collator_sort.o: In function `collator_regular_compare_function':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/collator/collator_sort.c:88: undefined reference to `ucol_strcoll_48'
and so on.

And at the end:
Code:
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/idn/idn.c:214: undefined reference to `uidna_IDNToASCII_48'
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/idn/idn.c:216: undefined reference to `uidna_IDNToUnicode_48'
ext/intl/idn/.libs/idn.o: In function `php_intl_idn_to_46':
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/idn/idn.c:132: undefined reference to `uidna_openUTS46_48'
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/idn/idn.c:150: undefined reference to `uidna_nameToUnicodeUTF8_48'
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/idn/idn.c:176: undefined reference to `uidna_close_48'
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/idn/idn.c:140: undefined reference to `uidna_nameToASCII_UTF8_48'
/usr/local/directadmin/custombuild/php-7.4.33/ext/intl/idn/idn.c:153: undefined reference to `uidna_close_48'

How does the /usr/lib/icu directory gets reinstalled? That might be the cause.
Also it's not clear to me why it says "uidna_close_48", is that 48 pointing to the old 48 version of icu?
 
Seems the /usr/lib/icu is not used anymore.

After I got this error, I tried again with a ./build clean, so
Code:
./build clean
./build php n
and then it worked.

You pointed me in the right direction! Thank you very much! Problem solved.
 
I don't think there is any reason for /usr/local/lib and /usr/local/include to exist.

Maybe in DirectAdmin of yesteryear where it compiled a lot of the libraries used for the various binaries that it compiled. But most of these are all compiled against system libraries now. I think DirectAdmin failed to realize that some older DirectAdmin installations still have the /usr/local paths.

Still, this is why I suggest renaming the directories instead of flat out removing them. Should there be a binary that depends on libraries compiled in /usr/local then it may be necessary to rename these back.

I suspect that PHP is still trying to compile against something else in /usr/local - which is why I suggest renaming the directories completely.
 
I don't think there is any reason for /usr/local/lib and /usr/local/include to exist.
They are on both my Centos 7.9 and Almalinux 8 servers. So it's not really yesteryear.
So why take the risk removing them when they are used on modern OS systems by Directadmin itself?

Some example from my Almalinux 8 server the /usr/local/lib content.
Code:
rw-r--r--   1 root root  13M 2023-08-09 00:52 libMagick++-7.Q16HDRI.a
-rwxr-xr-x   1 root root 1.4K 2023-08-09 00:52 libMagick++-7.Q16HDRI.la
lrwxrwxrwx   1 root root   30 2023-08-09 00:52 libMagick++-7.Q16HDRI.so -> libMagick++-7.Q16HDRI.so.5.0.0
lrwxrwxrwx   1 root root   30 2021-05-23 23:43 libMagick++-7.Q16HDRI.so.4 -> libMagick++-7.Q16HDRI.so.4.0.0
-rwxr-xr-x   1 root root 1.1M 2021-05-23 23:43 libMagick++-7.Q16HDRI.so.4.0.0
lrwxrwxrwx   1 root root   30 2023-08-09 00:52 libMagick++-7.Q16HDRI.so.5 -> libMagick++-7.Q16HDRI.so.5.0.0
-rwxr-xr-x   1 root root 5.1M 2023-08-09 00:52 libMagick++-7.Q16HDRI.so.5.0.0
and more of this, as you can see.... dated august this year. Not really wise to remove unless it's indeed only used to compile.

Then from my other newly installed Alma 8 server:
Code:
drwxr-xr-x.  3 root root 4.0K 2023-08-11 17:03 ImageMagick-7.1.1
drwxr-xr-x.  2 root root 4.0K 2023-08-11 21:57 ioncube
-rw-r--r--.  1 root root  13M 2023-08-11 17:03 libMagick++-7.Q16HDRI.a
-rwxr-xr-x.  1 root root 1.2K 2023-08-11 17:03 libMagick++-7.Q16HDRI.la
lrwxrwxrwx.  1 root root   30 2023-08-11 17:03 libMagick++-7.Q16HDRI.so -> libMagick++-7.Q16HDRI.so.5.0.0
lrwxrwxrwx.  1 root root   30 2023-08-11 17:03 libMagick++-7.Q16HDRI.so.5 -> libMagick++-7.Q16HDRI.so.5.0.0
-rwxr-xr-x.  1 root root 5.1M 2023-08-11 17:03 libMagick++-7.Q16HDRI.so.5.0.0
-rw-r--r--.  1 root root  34M 2023-08-11 17:03 libMagickCore-7.Q16HDRI.a
-rwxr-xr-x.  1 root root 1.1K 2023-08-11 17:03 libMagickCore-7.Q16HDRI.la
lrwxrwxrwx.  1 root root   33 2023-08-11 17:03 libMagickCore-7.Q16HDRI.so -> libMagickCore-7.Q16HDRI.so.10.0.1
lrwxrwxrwx.  1 root root   33 2023-08-11 17:03 libMagickCore-7.Q16HDRI.so.10 -> libMagickCore-7.Q16HDRI.so.10.0.1
-rwxr-xr-x.  1 root root  17M 2023-08-11 17:03 libMagickCore-7.Q16HDRI.so.10.0.1
-rw-r--r--.  1 root root 6.7M 2023-08-11 17:03 libMagickWand-7.Q16HDRI.a
-rwxr-xr-x.  1 root root 1.1K 2023-08-11 17:03 libMagickWand-7.Q16HDRI.la
lrwxrwxrwx.  1 root root   33 2023-08-11 17:03 libMagickWand-7.Q16HDRI.so -> libMagickWand-7.Q16HDRI.so.10.0.1
lrwxrwxrwx.  1 root root   33 2023-08-11 17:03 libMagickWand-7.Q16HDRI.so.10 -> libMagickWand-7.Q16HDRI.so.10.0.1
-rwxr-xr-x.  1 root root 3.7M 2023-08-11 17:03 libMagickWand-7.Q16HDRI.so.10.0.1
drwxr-xr-x.  2 root root 4.0K 2023-08-11 17:03 pkgconfig
So it looks as if Directadmin itself is still using this directory to create ioncube and imagick stuff.

In the /usr/local/include was the ImageMagick-7 directory on the new server. And on the older Alma 8 server a lot more, also from 2021 and 2022. For example this stuff.
Code:
drwxr-xr-x   2 root root 4.0K 2020-11-02 03:49 libexslt
drwxr-xr-x   2 root root 4.0K 2020-11-02 01:03 libpng
drwxr-xr-x   2 root root 4.0K 2020-11-02 03:44 libpng16
drwxr-xr-x   2 root root 4.0K 2020-11-02 01:10 libsodium
drwxr-xr-x   3 root root 4.0K 2020-11-02 01:08 libxml2
drwxr-xr-x   2 root root 4.0K 2020-11-02 03:49 libxslt
-rw-r--r--   1 root root 6.0K 2020-11-02 03:47 localcharset.h
-rw-r--r--   1 root root  12K 2020-11-02 03:46 ltdl.h
-rw-r--r--   1 root root   82 2020-11-02 03:46 mcrypt.h
-rw-r--r--   1 root root  223 2020-11-02 03:46 mhash.h

I rather don't remove directory's when I'm not sure if it's not used by something.

On my Centos 7 server, the /usr/lib/icu directory still exists too. Probably indeed because like this VPS, it has been used in the passed by DA, when the ./build icu command still worked.

So you say on the newer servers, it's only compile stuff, not used anymore (not even the imagick stuff?) and can be removed if needed?
 
Back
Top