WSL ROOT install "/usr/bin/ldd: line 160: /lib/ cannot execute binary file: Exec format error"

Hello, I’ve recently had to re-install my Windows 10, and this meant that my WSL for OpenSUSE LEAP 15.1 had to be re-installed as well.

I am quite familiar with cmake and installing many different versions of ROOT and right now I do have several systems running different version of ROOT in both full linux environment and WSL environment.

I downloaded the latest versions of ROOT5 and ROOT6 (July 2, 2020) and no problem in compilation.
Compilation flags are:
for ROOT6.22.00:

cmake -DCMAKE_INSTALL_PREFIX=$PWD -DGSL_DIR=/usr/local -Droofit=ON -Dpython3=OFF -Dminuit2=ON -Dmysql=OFF -Dxrootd=OFF -DPYTHON_EXECUTABLE=/usr/bin/python2 -Dgdml=ON -Dclad=OFF …/Downloads_old/root6source/

for ROOT5.34.38:

cmake -DCMAKE_INSTALL_PREFIX=$PWD/ -DGSL_DIR=/usr/local -Droofit=ON -Dpython3=OFF -Dminuit2=ON -Dmysql=OFF -Dxrootd=OFF -DPYTHON_EXECUTABLE=/usr/bin/python2 -Dgdml=ON …/Downloads_old/root5source/

Upon loading the root environments then execution I get an error:
“/usr/bin/ldd: line 160: /lib/ cannot execute binary file: Exec format error”.

This is a bit crazy. I did compile it myself on the WSL. It has worked in every other WSL+full linux environments, and the compiler should have thrown an error at me if something was wrong. I’ve triple-checked dependencies (, and I am running on a x86_64 system and no problem in compilation.

both ld and ldd are accessible and versions are as seen below.

/usr/bin/ldd --version
ldd (GNU libc) 2.26

/usr/bin/ld.bfd --version
GNU ld (GNU Binutils; openSUSE Leap 15.1)

I am out of ideas and have exhausted google search on this. Any ideas?


How exactly do you load the ROOT environment, could you paste the commands? Can you run root-config --features?


The root environment is loaded by sourcing /rootinstallation/bin/

As for root-config --features, I will get back to you because I am on full linux on the same laptop for the next few hours.

At the top of .bashrc I define

export native_path=$PATH
export native_ld_library_path=$LD_LIBRARY_PATH
alias nativeload=“export PATH=$native_path ; export LD_LIBRARY_PATH=$native_ld_library_path”;
alias root5load=“nativeload; source ~/ROOT5/bin/”
alias root6load=“nativeload; source ~/ROOT6/bin/”

Now, with root5 loaded root-config --features return:

root-config --features
asimage astiff bonjour builtin_afterimage builtin_ftgl builtin_glew builtin_lz4 cintex exceptions explicitlink fftw3 fitsio fortran gviz gdml genvector krb5 ldap mathmore memstat minuit2 python reflex roofit shadowpw shared sqlite ssl thread tmva vdt xft xml x11

Now, with root6 loaded root-config --features return:

root-config --features
cxx11 asimage builtin_afterimage builtin_clang builtin_llvm builtin_lz4 builtin_tbb builtin_vdt builtin_xxhash builtin_zstd dataframe exceptions fftw3 fitsio gdml http imt mathmore mlp minuit2 pyroot roofit runtime_cxxmodules shared sqlite ssl tmva tmva-cpu spectrum vdt x11 xml

I’ve tried OpenSUSE LEAP 15.2 WSL, and this error message is gone but I still wonder what caused this for reference since I don’t have this problem on any other computers

Edit: Error message returns just the same on LEAP 15.2 WSL

Ok, that is a good start. I must say that I don’t quite understand why it is seemingly looking for the 32bit The message “Exec format error”, does it show if you run root -l?

Could you, after sourcing, paste the output of

which root.exe
ldd $(which root.exe)
file $(which root.exe)
root-config --cflags --libs


I agree. I’m pretty sure it is looking for the 32bit package. This “shouldn’t” be a problem especially because I’ve compiled it within my 64bit WSL LEAP 15.1

Unfortunately I cannot answer your quoted questions because due to time sensitivity I’ve moved to LEAP 15.2.

Edited out …

Well, WSL LEAP 15.2 seems to have the exact same issue so I will continue from here. Same environment settings and variables.

The following is for ROOT6.22

~> which root.exe /home/SJLPHI/ROOT6/bin/root.exe

~> ldd $(which root.exe) /usr/bin/ldd: line 160: /lib/ cannot execute binary file: Exec format error (0x00007fffc7aac000) => /home/SJLPHI/ROOT6/lib/ (0x00007fbaee530000) => /home/SJLPHI/ROOT6/lib/ (0x00007fbaeddf0000) => /usr/lib64/ (0x00007fbaed9f0000) => /lib64/ (0x00007fbaed6b0000) => /lib64/ (0x00007fbaed490000) => /lib64/ (0x00007fbaed270000) => /lib64/ (0x00007fbaecea0000)
/lib64/ (0x00007fbaee800000) => /usr/lib64/ (0x00007fbaecc10000) => /usr/lib64/ (0x00007fbaec9d0000) => /lib64/ (0x00007fbaec7b0000) => /lib64/ (0x00007fbaec5a0000)

~> file $(which root.exe)
/home/SJLPHI/ROOT6/bin/root.exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, BuildID[sha1]=47b5ca8e63e0f28af3816a9230efb406cf54bf3d, for GNU/Linux 3.2.0, with debug_info, not stripped

~> root-config --cflags --libs
-pthread -std=c++11 -m64 -I/home/SJLPHI/ROOT6/include -L/home/SJLPHI/ROOT6/lib -lCore -lImt -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lROOTVecOps -lTree -lTreePlayer -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lMultiProc -lROOTDataFrame -pthread -lm -ldl -rdynamic

I think the weirdest part so far is that despite the error message. All the macros in the rootinstall/tutorials work, and the C++ programs that I’ve written, which do use root packages compile and run just fine.

Let alone the error message that shouldn’t be there that only seems to exist in WSL LEAP 15.1/15.2 installation on this specific computer.

I missed this part, but yes the error indeed still show when running root -l

The fact that the same error appears even if only ldd is called indicates that this is a problem of the LEAP environment rather than a problem with ROOT itself. I haven’t used ROOT on WSL myself but as far as I know the Ubuntu/WSL distribution works well for running ROOT.

ROOT works without any problem in every other WSL and full linux install including on LEAP 42.3/15.1/15.2 environment. It fully works on every other computer except this one. I just don’t get it because the way I installed it works in every other machines. This is not a problem with LEAP environment because I literally have machines next to me that has LEAP WSL with no problem and no error messages.

The only thing different in this installation is that this is on fresh brand-new installation of Windows 10. I read that a new filesystem is used on the new version of Windows 10 whereas updated version of older installation of W10 inherits the older version of the FS and that WLS works funky with the new FS.

In any case do you have more suggestions for diagnosing what may be wrong?

Just to make it more confusing… I’ve cloned the WSL with successful ROOT installation on other computer and applied it to this machine. Result, the error message appears again…

I have a feeling that there is something funny about how W10’s new FS interacts with and/or some environmental variable has been called from WSL for this new installation of W10.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.