Could not compile ROOT with installROOT.sh

Newbie
1

Hi,

I am trying to compile REST (after copying it from the development branch) on the Ubuntu 20.04.1 LTS.
I have already installed all the required software (by a installRequiredSoftware.sh script).

After trying to install ROOT with appropriate script installROOT.sh I receive an error stating that the configuration is incomplete.
CMakeError.log states that -lpthreads cannot be found.
I have set an environmental variable LD_LIBRARY_PATH=/usr/lib just in case cmake could not locate different libraries but nothing has changed.
I am not sure where to locate such a problem. Could you, please help me?

I have attached CMakeOutput.txt (69.7 KB)
and CMakeError.txt (2.9 KB) here just in case it would be useful.

Thank you in advance.

2

One thing I can think of is that you have overridden the original LD_LIBRARY_PATH definition.

You should be careful to just add new paths to your LD_LIBRARY_PATH and dont reinitialise it.

If you do export LD_LIBRARY_PATH=/usr/lib then the system will only be able to find libraries at that location.

You should always add new paths.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib

Although usually /usr/lib should be there by default.

Also, there is some priority, if you want the new /usr/lib to be searched for first, then you should add it in from any other definitions.

export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH

Hope that’s the problem. It looks like, because pthread is a system library, never remember installing something similar in any system, they come by default.

3

Just to clarify:
While it is true that running the first command will of course override any previous value of the LD_LIBRARY_PATH variable, that is usually not a problem. Most Linux distributions don’t really use LD_LIBRARY_PATH at all. Meaning any binary installed system wide won’t depend on it.

Instead ld.so (the dynamic linker) 1 has its own set of paths it searches. To see what those are, you can run ldconfig -v. 2
The paths searched by it are defined by the configuration files on most distributions found under /etc/ld.so.conf.d. The files there simply contain one or more lines of paths containing shared libraries.
One is free to add new files there (better not modify existing ones, since your changes might be overwritten by updates) containing new paths to search.
As a matter of fact any program that one is going to use a lot (e.g. ROOT or REST) one really shouldn’t depend on LD_LIBRARY_PATH. Usually those things aren’t a problem, because most users will run something along the lines of sudo make install after compiling things like ROOT. That usually takes care of putting the libraries in places searched by the ld.so (typically /usr/local/lib or /opt/lib` for the libraries).

After adding a new path, one needs to run ldconfig with super user access.

Specifically why the error appears I can’t say for sure either. I would check whether libpthread.so actually exists on my system first (but it really should) and is where I expect it to be (namely a path searched by ld.so):

sudo updatedb # just to make sure that mlocate's database is up to date
locate libpthread.so

If locate isn’t installed, search manually using find or simply ls in the typical directories.

Ah, just checked the CMakeError.txt file. Since you seem to be getting a couple of undefined reference errors (so it can find the library, but it’s not meeting it’s demands, which is why it says it can’t find it):

/usr/bin/ld: src.c:(.text+0x52): undefined reference to `pthread_detach'
/usr/bin/ld: src.c:(.text+0x63): undefined reference to `pthread_join'

From that error it could be a version mismatch (e.g. version of libpthread.so is too old) or some weird quirk with clang (you’re on a Mac I assume from your paths, right?)
gcc at least is quite picky where lpthread / -pthread go.

4

Hi Sebastian, thanks for all those details, it is good to know about that. Perhaps the system meshed up between /usr/lib/ and /usr/lib64 or similar when adding to LD_LIBRARY_PATH? Do ldconfig linked libraries have priority over anything defined in LD_LIBRARY_PATH?

I understand now that this is not required for system linbraries, just to clarify we do depend for our own user libraries, it is /path/to/root/installation/bin/thisroot.sh and /path/to/rest/installation/thisREST.sh the responsibles to define the right LD_LIBRARY_PATH variables.

This allows us to change the version of REST from the command line just by sourcing different installation locations.

First line of CMakeOutput says he is on Linux.

===

Most common problems with ROOT 6.20 installation are usually problems to find python development libraries. I have never seen problems with pthread this might be something related to the system.

5

Perhaps the system meshed up between /usr/lib/ and /usr/lib64 or similar when adding to LD_LIBRARY_PATH?

Specifically what might have happened in OPs case, I have no idea unfortunately.

Do ldconfig linked libraries have priority over anything defined in LD_LIBRARY_PATH?

ld.so has the following search priorities, see 1 under the description before “Dynamic string tokens”:
0. if library name contains a slash it’s considered a direct path to the file

  1. DL_RPATH / DT_RUNPATH specified in the binary (linked at compile time)
  2. LD_LIBRARY_PATH
  3. Directories mentioned by DT_RUNPATH for those tagged with DT_NEEDED (1. and 3. is confusing to me)
  4. the cache file /etc/ld.so.cache. That’s the file being generated from the config files in /etc/ld.so.conf.d/ when running sudo ldconfig
  5. Default paths /lib and /usr/lib, or on 64bit systems /lib64/ and /usr/lib64`

So yes, LD_LIBRARY_PATH takes precedent over the custom paths and default paths (unless compile time linking is done, in which case that takes precedent over both).

I understand now that this is not required for system linbraries, just to clarify we do depend for our own user libraries, it is /path/to/root/installation/bin/thisroot.sh and /path/to/rest/installation/thisREST.sh the responsibles to define the right LD_LIBRARY_PATH variables.

This allows us to change the version of REST from the command line just by sourcing different installation locations.

Oh, it’s perfectly fine to do that as a developer of a tool! For the average user however it’s really better to provide a sane way that is not dependent on a shell environment variable that might get overwritten by some other random shell script. Because that can lead to some really annoying errors (especially wrt bug reports).

First line of CMakeOutput says he is on Linux.

Huh, indeed. I’m confused though by the paths such as:

/local/home/al264242/Documents/Soft/root-6.20.00/build/CMakeFiles/CMakeTmp/src.c

that doesn’t look like any path I would expect to find on a normal linux distribution and I know that Macs have weird paths (but different apparently, I checked again).
The capital “Documents” makes it seem like Windows. My Debian WSL (windows subsystem for linux) also has different paths though, so I’m still confused about it. :slight_smile:

1 Like
6

Thank you Javier and Sebastian for your help.

I can locate libpthread.so at the directory /usr/lib/x86_64-linux-gnu/.
Just in case I added such line to the .bashrc :

export LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib:/usr/lib:$LD_LIBRARY_PATH

but it didn’t help.
All my packages are up to date, thus I don’t understand where this problem comes from.

7

The script defined at REST installROOT.sh is just downloading, and launching cmake, make and make install

I suggest that at this point you move to run those commands manually.

Try removing any definitions from LD_LIBRARY_PATH in your bashrc or wherever you define them.

Launch a new terminal and print out the contents of LD_LIBRARY_PATH

echo $LD_LIBRARY_PATH

Then go to the ROOT6 build directory generated by ./installROOT.sh

cd $HOME/root-6.20.00/build

clean all contents

rm -r *

and re-populate the build directory

cmake -Dgdml=ON -DCMAKE_INSTALL_PREFIX=../install ../source

If there are errors attach te full output here

8

I tried this and still have the same problem.

Also,

gives nothing in the output after I removed other definitions from LD_LIBRARY_PATH.

I attached the CMakeOutput and CMakeError files here.
CMakeOutput.txt (69.7 KB)
CMakeError.txt (2.9 KB)

9

Try this now

What it is the output of the following?

find /lib -name "*pthread*"

and

nm /lib/x86_64-linux-gnu/libpthread.so.0 | grep "pthread_create"

Plz,attach directly the output you get on screen.

10

Thank you for the link.

the output gives nothing, but when I execute find -name "*pthread*" directly from the /lib directory I am able to find libpthread.so:

al264242@dphnpcl147:/lib$ find -name “pthread”
./x86_64-linux-gnu/libpthread.a
./x86_64-linux-gnu/libpthread.so.0
./x86_64-linux-gnu/pkgconfig/pthread-stubs.pc
./x86_64-linux-gnu/samba/vfs/aio_pthread.so
./x86_64-linux-gnu/libgpgme-pthread.so.11
./x86_64-linux-gnu/perl/5.30.0/bits/pthreadtypes-arch.ph
./x86_64-linux-gnu/perl/5.30.0/bits/pthreadtypes.ph
./x86_64-linux-gnu/libevent_pthreads-2.1.so.7
./x86_64-linux-gnu/libevent_pthreads-2.1.so.7.0.0
./x86_64-linux-gnu/libpthread-2.31.so
./x86_64-linux-gnu/libpthread.so

This line gives me an output as it should:

al264242@dphnpcl147:/lib$ nm /lib/x86_64-linux-gnu/libpthread.so.0 | grep “pthread_create”
00000000000098d0 t __pthread_create_2_1
0000000000007af7 t __pthread_create_2_1.cold
00000000000098d0 T pthread_create@@GLIBC_2.2.5

11

Hello Andriii,

The most convenient command to search for available libraries is ldconfig -p. E.g:

$ ldconfig -p | grep libpthread
	libpthread.so.0 (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/libpthread.so.0
	libpthread.so.0 (libc6,x86-64, OS ABI: Linux 2.6.32) => /lib/x86_64-linux-gnu/libpthread.so.0
	libpthread.so.0 (libc6, OS ABI: Linux 2.6.32) => /lib/i386-linux-gnu/libpthread.so.0
	libpthread.so.0 (libc6, OS ABI: Linux 2.6.32) => /lib32/libpthread.so.0

Yann

12

Hi Yann,

Thank you.
With ldconfig -p command I can locate pthread libraries as follows:

al264242@dphnpcl147:~$ ldconfig -p | grep libpthread
libpthread.so.0 (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib/x86_64-linux-gnu/libpthread.so

13

What if you compile the following code?

#include <pthread.h>

void* test_func(void* data)
{
  return data;
}

int main(void)
{
  pthread_t thread;
  pthread_create(&thread, NULL, test_func, NULL);
  pthread_detach(thread);
  pthread_join(thread, NULL);
  pthread_atfork(NULL, NULL, NULL);
  pthread_exit(NULL);

  return 0;
}

using

gcc -o pthread_test source_file.c -lpthread

It compiles without problems?

14

Yes, I have no errors compiling this code.

Also, regarding the discussion by the link you provided:
I cannot find the Configuring incomplete, errors occurred! notification neither inside the CMakeError.log nor inside the CMakeOutput.log.

15

I usually see that output directly on screen.

See for example the outputs at this post at root-forum

16

Hi Javier,

It looks like the problem was with missing dependencies on my computer.

I asked the same question on the ROOT forum:

Thus, after installing these packages

apt -y update && apt -y upgrade && apt-get install dpkg-dev cmake g++ gcc binutils libx11-dev libxpm-dev libxft-dev libxext-dev python libssl-dev gfortran libpcre3-dev xlibmesa-glu-dev libglew1.5-dev libftgl-dev libmysqlclient-dev libfftw3-dev libcfitsio-dev graphviz-dev libavahi-compat-libdnssd-dev libldap2-dev python-dev libxml2-dev libkrb5-dev libgsl0-dev wget git

least one of them was missing and I managed to compile root.

Thank you very much for your help!

P.S. Could it be possible to add (at least) several packages to the installRequiredSoftware.sh?

1 Like
17

Ok, that’s a good idea, I will do. Although that’s only working for apt based systems.