[Insight-users] GLIBC not found

Luis Ibanez luis.ibanez at kitware.com
Thu May 26 18:40:39 EDT 2011


Hi All,


After debugging this problem in an interactive session
with Sara today, we figured out how to build ITK correctly
in her cluster.


Here is a summary,
just to close the loop in this thread:

-----------------------------------------------------------------------------

1) The cluster setup is the following:

 a) One master node with 32-bits architecture
    running RHLE.

 b) 32 computational nodes with 64-bit architecture,
    running RHLE. Each node with 16-core processors.

 c) Users could login into the master node as well
    as the computational nodes.

 d) The cluster has access to a share directory
    system, where the "HOME" directory of the user
    is always mounted, but where the "system" directories
    are different depending on the node that the user
    logs in.  For example, when loging in the master 32-bits
    node, the /usr/lib, /usr/bin... directories are different
    from the ones that are visible in those same locations
    when login in one of the 64-bits computational nodes.

 e) Due to the difference in architecture (32 vs 64 bits) and
    the difference in location of system libraries. A build of
    ITK made in the 32-bits node could not possibly run in one
    of the 64-bits computational nodes. (unless we go through
    the effort of crosscompiling for 64bits in a 32 bits node...)

 f) Therefore, we opted for building ITK and some examples
    directly in one of the 64-bits nodes.


2) The system administrator had installed the libuuid developent
  library in the system directories of the 64-bits computational
  nodes.  The library was in /usr/lib64/  as  libuuid.so, and was
  a symbolic link to another library in /lib64/libuuid.1.so that
  in turn was a symbolik link to /lib64/libuuid.1.2.so.


3) ITK 3.20, in its gdcm directory has a setup for finding the
  UUID library and its headers. This is in the file:

        Insight/Utilities/gdcm/CMake/FindUUID.cmake

  In this file, the default locations where CMake is expected
  to look for the libuuid library are defined in the lines 27-30:

      FIND_LIBRARY(UUID_LIBRARY
        NAMES ${UUID_LIBRARY_VAR}
        PATHS /lib /usr/lib /usr/local/lib
        )


  In order to guide CMake to find the libuuid library in the
  expected /usr/lib64 directory we modifed this FindUUID.cmake
  file to have the following code:

      FIND_LIBRARY(UUID_LIBRARY
        NAMES ${UUID_LIBRARY_VAR}
        #  PATHS /lib /usr/lib /usr/local/lib
        PATHS /usr/lib64
        )


4) We put the source tree of ITK in the user's home directory
  under

         $HOME/ITK/src/InsightToolkit-3.20

  and created a directory for the binary build under:

         $HOME/ITK/bin/ITK-3-20-x86_64

  We intentionally named the directory to indicate that
  this ITK libraries were compiled in a 64-bits architecture.


5) Using a cmake that was build locally in the home directory
  of the user, we configured ITK 3.20 with:

         CMAKE_BUILD_TYPE   = Release
         BUILD_EXAMPLES     = OFF
         BUILD_TESTING      = OFF


  The configuration went smoothly, and then we build ITK.
  To take advantage of the 16 cores available in this node
  we used the command:

                    make   -j 14

  (left two cores available to make sure that our shell
   login was still responsive).


5)  Once ITK finished building. We tested also in the user's
   home directory, two of the ITK examples. We did:

   $HOME/ITK/src/examples/example1/HelloWorld.cxx

   and

   $HOME/ITK/src/examples/example2/MedianImageFilter.cxx

   We created CMakeLists.txt files for both of them,
   and also created binary directories for them respectively:


           $HOME/ITK/bin/examples/example1
           $HOME/ITK/bin/examples/example2

   When configuring these binary directories with CMake
   we pointed the ITK_DIR variable to the build of ITK in
   the user's home directory:

         $HOME/ITK/bin/ITK-3-20-x86_64

   This configuration process went smoothly,
   as it did the build process (just typing "make").


6)  To verify the builds. We logged in into another one
   of the 64-bits computational nodes, and from there
   ran the executable.

   We verified that we could do:

   ./MedianImageFilter BrainProtonDensitySlice.png output.png

   and that the output.png image file was properly
   generated.

   We also verified that the MedianImageFilter was
   depending on the right shared libraires.

   In particular, by doing:

       ldd   ./MedianImageFilter

   we verified that it was depending on

            /usr/lib64/libuuid.so


-------------


The take home message is:

When building ITK (or any other software for that matter...)
to be run in a Cluster. The build should be done for the
architecture and run-time environment of the nodes where
the code will ultimately be run.

This could be achieved by:

  a) cross-compiling (for the target architecture)
     in the master node.

   or

  b) compiling directly in the computational nodes
     (assuming that you have access to them and that
      a build environment has been installed (gcc, ld, etc).

   or

  c) compiling in an external machine that has the same
     architecture as the computational nodes, and then
     copying the executable to a directory that is accessible
     to the computational nodes.

  in this particular case we did (b).


-------------------------------------------------------------

On Thu, May 26, 2011 at 12:45 PM, Sara Rolfe <smrolfe at u.washington.edu> wrote:
> Hi Luis,
>
> The version of ITK I'm using is 32-bit and the machine I want to run it on
> is 64-bit.  If I compile it on this machine it tries to compile it as a
> 64-bit program and I get a lot of errors.  I'm not sure how to force it to
> compile in 32-bit mode since the first 64-bit machine I tried did this by
> default.
>
> I will look into this, but please let me know if you have any thoughts.
>
> Thanks,
> Sara
>
> On May 26, 2011, at 8:58 AM, Luis Ibanez wrote:
>
>> Hi Sara,
>>
>> It looks like you copied an executable from one Linux machine
>> into another, and that the libc versions between the two are
>> incompatible.
>>
>> Any chance that you can actually compile you program in the
>> same machine where you are planning to run it ?
>>
>>
>>    Luis
>>
>>
>>
>> ----------------------------------
>> On Wed, May 25, 2011 at 5:51 PM, Sara Rolfe <smrolfe at u.washington.edu>
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm attempting to run a program using ITK on a 64-bit Linux machine and
>>> am
>>> getting the following error:
>>>
>>> ./SubsampleVolume: /lib/libc.so.6: version `GLIBC_2.7' not found
>>> (required
>>> by /projects/multimedia1/InsightToolkit-3.14.0/bin/libITKniftiio.so.3.14)
>>>
>>> I've run this without a problem on a Mac OS, 32-bit Linux and a different
>>> 64-bit Linux machine.  Could you let me know if you know what this is
>>> referring to or how to resolve it?
>>>
>>> Thanks,
>>> Sara
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>
>


More information about the Insight-users mailing list