Cannot get symbol ucol_setMaxVariable_50 from libicui18n

[abarberenaCPDS]

After following the steps here, https://dotnet.microsoft.com/download/dotnet/thank-you/sdk-5.0.103-linux-arm64-binaries. I am getting the following exception when running:

dotnet --version

Cannot get symbol ucol_setMaxVariable_50 from libicui18n
Error: /lib64/libicui18n.so.50: undefined symbol: ucol_setMaxVariable_50
[1]    8639 abort      dotnet --version

Environment:

• Raspberry Pi 3B+
• Micro Center 32GB microSDHC Card Class 10
• Clean install of Centos aarch64 RPI Minimal 4

name -a
Linux centosraspberrypi 5.4.72-v8.1.el7 dotnet/sdk
#1 SMP PREEMPT Wed Oct 21 17:35:36 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[phillip-haydon]

I'm getting the same issue.

@abarberenaCPDS

https://gist.github.com/Sunlighter/fe602d2a090e64a01c3369fe7d7d7325

This worked for me.

[dsplaisted]

@agocke @lakichemole @vitek-karas @tarekgh Can one of you triage or route this as appropriate? Thanks.

[tarekgh]

This looks the runtime bits was built on a machine which is using ICU version greater than 52 which is statically link against ucol_setMaxVariable that is not available on ICU version prior to 53.

runtime/src/libraries/Native/Unix/System.Globalization.Native/configure.cmake

Line 19 in 5255bbb

ucol_setMaxVariable

I am trying to find a contact who can help with that.

The workaround for this issue, install ICU version higher than 52 on the machine that is failing with this error. I am not sure if such distros provide such option though.

[tarekgh]

@janvorli do you know who can help with this issue?

[tarekgh]

CC @MichaelSimons

[tarekgh]

CC @dleeapho

[tarekgh]

@abarberenaCPDS is there a way you can try to upgrade the installed ICU package? or tell how I can get Linux centosraspberrypi image to try? @phillip-haydon comment https://github.com/dotnet/sdk/issues/16009#issuecomment-901639066 has a good workaround to try too.

[tarekgh]

@dsplaisted I am not the right one to assign here. I am trying to figure out who can help.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

After following the steps here, https://dotnet.microsoft.com/download/dotnet/thank-you/sdk-5.0.103-linux-arm64-binaries. I am getting the following exception when running:

dotnet --version

Cannot get symbol ucol_setMaxVariable_50 from libicui18n
Error: /lib64/libicui18n.so.50: undefined symbol: ucol_setMaxVariable_50
[1]    8639 abort      dotnet --version

Environment:

Linux centosraspberrypi 5.4.72-v8.1.el7 dotnet/sdk#1 SMP PREEMPT Wed Oct 21 17:35:36 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

Author:	abarberenaCPDS
Assignees:	-
Labels:	area-Infrastructure, untriaged
Milestone:	-

[tarekgh]

@@abarberenaCPDS please let's know if the workaround is working for you.

[tarekgh]

another idea to work around this is to use the ICU app-local feature

Include the following in your csproj:

  <ItemGroup>
    <RuntimeHostConfigurationOption Include="System.Globalization.AppLocalIcu" Value="68.2.0.6" />
    <PackageReference Include="Microsoft.ICU.ICU4C.Runtime" Version="68.2.0.6" />
  </ItemGroup>

[abarberenaCPDS]

@tarekgh , let me try right now, I'll post the details shortly, thx for following up!

[abarberenaCPDS]

Hey @tarekgh, sorry for the late reply, I took some days off. I wanted to report that sadly I couldn't make it work, I even tried with a fresh install:

• I tried your ZIP, then build ICU and still did not work.
• I tried compiling the GCC again and no luck

[tarekgh]

@abarberenaCPDS thanks for your reply. what is the error you are currently getting?

[abarberenaCPDS]

Hey man, I am still getting the same error I reported at the top of this thread:

ucol_setMaxVariable_50 from libicui18n

Also, I've tried with several versions of ICU, from the ones that did not require namespace and even the latest release. I am still wondering what might be the issue.

[tarekgh]

From the error you have, it looks ICU was not installed correctly.

Just to confirm, after building ICU v53 you have done the following two steps:

make install
export LD_LIBRARY_PATH=/home/user/libicu/lib/

Also, would be good adding export LD_LIBRARY_PATH=/home/user/libicu/lib/ to $HOME/.bashrc then try again.

[abarberenaCPDS]

Hey @tarekgh, yes, you're right, ICU is a blocker for me.

Keep in mind that we already tried to enable GCC and did not work, we also tried with the compiled libs and still the same.

ICU can't successfully build due to configure: error: Namespace support is required to build ICU.

~/icu53source/icu-release-53-2/icu4c/source> ./configure --prefix=/home/root/libicu

checking for ICU version numbers... release 53.2, library 53.2, unicode version 6.3
checking build system type... aarch64-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking whether to build debug libraries... no
checking whether to build release libraries... yes
checking for clang... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for clang++... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for gmake... /usr/bin/gmake
checking for doxygen... no
checking checking for executable suffix...
checking whether strict compiling is on... yes
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking size of void *... 8
checking whether runnable 64 bit binaries are built by default... yes
checking which Makefile fragment to use for aarch64-unknown-linux-gnu... mh-linux
checking for floor in -lm... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether to enable auto cleanup of libraries... no
checking whether to enable draft APIs... yes
checking for ranlib... ranlib
checking for ar... ar
checking whether to enable renaming of symbols... yes
checking whether to enable function and data tracing... no
checking elf.h usability... yes
checking elf.h presence... yes
checking for elf.h... yes
checking whether to enable dynamic loading of plugins... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for library containing dlopen... -ldl
checking for dlopen... yes
checking for gettimeofday... yes
checking if we have a C++ compiler... Good
checking if #include <string> works... yes
checking if #include <atomic> works... yes
checking for pthread_attr_init in -lpthread... yes
checking for mmap... yes
checking for genccode assembly... -a gcc
checking for inttypes.h... (cached) yes
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking whether byte ordering is bigendian... no
checking for nl_langinfo... yes
checking for nl_langinfo's argument to obtain the codeset... CODESET
checking for namespace support... no
configure: error: Namespace support is required to build ICU.

[Kaelum]

In another thread, I found the following:

sudo yum install libicu60

Once I ran that, .NET 5.0 was working on an AWS Linux 2 ARM64 instance.

[abarberenaCPDS]

Hey @Kaelum, thanks for your comment, I appreciate your help but unfortunately the solution is not applicable in this case.

Keep in mind that the architecture I am using is a clean install of Centos aarch64 RPI Minimal 4

Package libicu-50.2-4.el7_7.aarch64 already installed and latest version
Nothing to do

Reference

• Image version: Libicu50

[janvorli]

@abarberenaCPDS please note that CentOS 7 is not supported for arm/arm64. See the support matrix here: https://github.com/dotnet/core/blob/main/release-notes/5.0/5.0-supported-os.md. arm/arm64 is only supported on Ubuntu, Debian and Alpine. The reason is that we cross build for arm/arm64 distros on x64 devices and our scripts to generate rootfs don't support targeting redhat based distros. The distros that we target use newer libc / icu / etc. So while things might work if you upgrade the libc on CentOS 7 and build / install a newer libicu, replacing libc in a distro is a potential issue for some low level OS functionality where it is expected that libc and some other libraries match.

[tarekgh]

I am closing this issue per @janvorli comment. @abarberenaCPDS feel free to send any more question we can help with if you have any. Thanks for your report.

[abarberenaCPDS]

Hey @janvorli, thanks for the link, that makes sense. I think I am going to suggest to MS to add this matrix in the Download .NET page. It is extremely useful. 👍

I am still wondering how @tarekgh was able to successfully build LibIcu using the same image I referenced and run NetCore with no issues. That makes me cringe 😢.

Say, should I just follow this link .NET Release notes, I would never figured that out myself any easier.

[tarekgh]

I am still wondering how @tarekgh Tarek Mahmoud Sayed FTE was able to successfully build LibIcu using the same image I referenced and run NetCore with no issues. That makes me cringe 😢.

I think the only step you couldn't do is what I mentioned in my comment #57983 (comment). In my case, although took long time but was successfully completed and helped in compiling ICU v53 after that. The only difference I had is my micro SD card I used was 64 GB and I used Aluminum Heat Sink

[abarberenaCPDS]

@tarekgh, I can't thank you enough for your assistance and time spent in this issue 🥇.

It was very good to connect with you and I can say I learned a lot. I will try with a bigger card, that might be the problem.

Abe

[tommcdon]

@abarberenaCPDS @tarekgh Copying text from #66325 (comment) to this GH issue for continuity

---

Cannot get symbol ucol_setMaxVariable_50 from libicui18n

Hi @tarekgh 👋 , I know it's been a long time, however, I just wanted to give you an update in regards to #57983.

I was able to successfully run dotnet 5! 🚀 🥳 🤟

Linux centospi 5.4.72-v8.1.el7 #1 SMP PREEMPT Wed Oct 21 17:35:36 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

Observations

The only difference this time, was to use a better Micro SD card

• 32 GB SanDisk Extreme

I followed the same steps, I did not compile ICU and used your zipped (pre-compiled) libraries.

PS:

• I couldn't append the results to ticket since now is closed. hopefully there's a way to add this info to provide continuity.
• Should anyone else have or would ever face the same issue, feel free to reach out and/or chime in.