Conflicting libstdc++.so.6: versions of GLIBCXX when compiling ORIGEN from SCALE source with local modifications on Ubuntu Linux 16.0.4

[jdetroullioud]

Hi all,


I am trying to recompile Scale6.2 ORIGEN source codes on my Ubuntu 16.0.4 system.

The compilation goes well and I thus end up with freshly compiled binaries for ORIGEN and other ORIGEN related bin in my build/INSTALL/bin directory as well as freshly compiled associated libraries in build/INSTALL/lib.

Now, what I do is that I replace the original bin in SCALE6.2/bin with my freshly compiled bins. Then I run an ORIGEN test case that I wrote and that works fine with the original bin.

However, I run into the following error in the command line:

                  Job Information
                  ---------------
      Job started on julien-HP-Z1-G2-Workstation on 周日 20/11/2016 15:23:10
      Working directory: /tmp/scale.julien.24975
      Input file name  : /home/julien/google/Princeton/oix/Scale6.2_ex/origen/test1/test1
      Output file name : /home/julien/google/Princeton/oix/Scale6.2_ex/origen/test1/test1.out
      SCALE executable : /scale/SCALE-6.2/bin/../bin/scale
     
 *******************************************************************************

  Now executing couple                         
/scale/SCALE-6.2/bin/../bin/origen: /scale/SCALE-6.2/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /scale/SCALE-6.2-serial-6.2-Source/build3/INSTALL/lib/libOrigenManager.so.06)
/scale/SCALE-6.2/bin/../bin/origen: /scale/SCALE-6.2/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /scale/SCALE-6.2-serial-6.2-Source/build3/INSTALL/lib/libOrigenManager.so.06)
/scale/SCALE-6.2/bin/../bin/origen: /scale/SCALE-6.2/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /scale/SCALE-6.2-serial-6.2-Source/build3/INSTALL/lib/libOrigenCore.so.06)
/scale/SCALE-6.2/bin/../bin/origen: /scale/SCALE-6.2/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /scale/SCALE-6.2-serial-6.2-Source/build3/INSTALL/lib/libOrigenCore.so.06)
Scale job /home/julien/google/Princeton/oix/Scale6.2_ex/origen/test1/test1 is finished.
Output is stored in /home/julien/google/Princeton/oix/Scale6.2_ex/origen/test1/test1.out


The problem, if I understand correctly, is that the libraries that I compiled needs these "GLIBCXX_3.4.20“ and "GLIBCXX_3.4.21" from /scale/SCALE-6.2/bin/../lib/libstdc++.so.6. I checked with using strings libstdc++.so.6 | grep GLIBCXX and the ouput indeed shows that GLIBCXX_3.4.20 and GLIBCXX_3.4.21 are missing.

My current gcc version is 5.4.0 and I thought of switching to an older gcc compiler (even if the manual says that compilation should be fine with all gcc 4.8.3+ versions). That might solve this problem but switching gcc version is not as easy as I thought (I am working on it).

Do someone have an idea on how to deal with this problem?

Thanks a lot.


Julien

[Will Wieselquist]

Is it possible your LD_LIBRARY_PATH is not set correctly--correctly means finding the same libraries as were found at compilation time. E.g. see https://developer.ibm.com/answers/questions/184266/libstdcso6-version-glibcxx-3420-not-found.html. 

+W

[Will Wieselquist]

If this isn't it, could you also post the cmake command you used to configure and the output of the cmake configure?

+W

[jdetroullioud]

Will,


Thank you for you fast reply.

Concerning, the LD_LIBRARY_PATH I am not sure of what I should do. It does not have any directory related to scale6.2 in it but it does not seem to matter since my recompiled components look like they are finding their ways to the Scale6.2 libstdc++.so.6 without problem. In addition, if I should change something on my LD_LIBRARY_PATH, I really don't know what I should add. Looks like the libstdc++.so.6 my compiled libraries try to use are internal to Scale6.2, they are not the one from my system. There is then something that already indicates the path to these c++ internal libraries to my recompiled libraries. Surprisingly, these Scale6.2 libstdc++.so.6 do not look to be up to date with the latest gcc.

Concerning your second request, this is all the steps I do from creating a new build to compilation:

mkdir build
cd script
cp configure_scale_gnu.sh ../build
cd build
chmod u+x configure_scale_gnu.sh
./configure_scale_gnu.sh ..
sudo make -j 8
sudo make install

I attached the .log file from the Cmake configuration I did last.

Finally, regarding the packages I am trying to compile, there is something you might help me to clarify. I basically want to modify the file depletion.f90 that is located in SCALE-6.2-Source/packages/Origen/Manager/wrap. But I also noticed that there is a second Origen folder in SCALE-6.2-Source/packages/Sequence/Origen/origen. What is important to note is that if I only make/make install from /packges/Origen running scale works. The same is true if I only make/make install from /packages/Sequence/Origen/origen. However, make/ make install in both lead to the error I indicated above. May be I should only try to make/make install from /packges/Origen. But what intrigues me is that if I do that, no Origen bin is compiled (hence why I also felt necessary to make/make install from /packages/Sequence/Origen/origen).
Am I doing something wrong here?

Thank you for your help.


Julien

[Will Wieselquist]

Hey Julian, 

I can't say I fully understand what is going on, but I would change a few things about your configure/build process. This is the configure script you are using as I have it:

#!/bin/bash

##---------------------------------------------------------------------------##

## script/condigure_scale_gnu.sh

## This script is for serial SCALE build

##

## Kursat Bekar

## Fri Apr  1 14:37:12 EDT 2016

##---------------------------------------------------------------------------##

#

#

# Set where we will install binaries

# Default to binary directory/INSTALL

#

export INSTALL_PATH=${PWD}/INSTALL

#

# Remove CMakeCache and Files

#

if [ -e CMakeCache.txt ] ; then

   rm -rf CMake*

fi

#

# Detect a default package list

#

if [[ ! "$1" =~ ^/ ]] ; then

   INTERNAL_LIST="${PWD}/${1}/script/options_scale_packages.cmake"

else

   INTERNAL_LIST="${1}/script/options_scale_packages.cmake"

fi

#

# Allow user to set PACKAGE_LIST_PATH in their environment

#

export PACKAGE_LIST_PATH=${PACKAGE_LIST_PATH:-${INTERNAL_LIST}}

#

# Set default compilers

#

export CC=${CC:-gcc}

export CXX=${CXX:-g++}

export F90=${F90:-gfortran}

#

# Scale Data

#

DATA=/scale/scale_dev_data

#

# TPLs

#

LAPACK=/opt/vendors/gcc-4.8.3/shared/lib/

cmake \

   -D SCALE_CONFIGURE_OPTIONS_FILE:FILEPATH=${PACKAGE_LIST_PATH} \

   -D BUILD_SHARED:BOOL=ON \

   -D SCALE_DATA_DIR:STRING="${DATA}" \

   -D DART_TESTING_TIMEOUT:STRING=3500 \

   -D SCALE_ENABLE_TESTS:BOOL=ON \

   -D SCALE_ENABLE_REGRESSION_TESTS:BOOL=ON \

   -D ENABLE_PYTHON_WRAPPERS:BOOL=OFF \

   -D SCALE_ENABLE_SAMPLE_TESTS:BOOL=ON \

   -D CMAKE_BUILD_TYPE:STRING=RELEASE \

   -D CMAKE_INSTALL_PREFIX:STRING=${INSTALL_PATH} \

   -D TPL_LAPACK_LIBRARIES:STRING=${LAPACK}/liblapack.so \

   -D TPL_BLAS_LIBRARIES:STRING=${LAPACK}/libblas.so \

   -D CMAKE_Fortran_COMPILER:STRING=${F90} \

   -D CMAKE_CXX_COMPILER:STRING=${CXX} \

   -D CMAKE_C_COMPILER:STRING=${CC} \

   $*

Hopefully yours is similar/the same. I'm assuming you redefined your LAPACK=/opt/vendors/gcc-4.8.3/shared/lib/ for your system on the local configuration file but that doesn't appear to be a problem. This is how I do it:

mkdir build
cd script
cp configure_scale_gnu.sh ../build/do-config.sh
cd build
source do-config.sh .. && make -j8 install

I use "source" instead of running configure as an executable because then you can be sure that your current environment will be what the cmake command sees. If you run configure as an executable, then the variables you define ONLY exist in the new shell created for the execution. This may not be an issue, but I am more comfortable when I and cmake see the same environment.

I would also not use sudo because I never use sudo and you're just installing locally anyway, e.g. in build/INSTALL. 

To answer your question about what to make and why executables aren't getting updated: because this is a "shared build", the executables are all dynamically linked to what's in your INSTALL/lib directory, so I would just 'cd packagers/Origen/Manager/wrap' and 'make -j8 install' from there after any modifications. This will install the modified library which will be picked up by all executables that depend on it. Alternatively, you could changed the line to "-D BUILD_SHARED:BOOL=OFF" which enables a "static" build where all symbols that an executable needs are included in that executable. It makes executables larger but then they don't really have dependencies and you can move them around, e.g. to other linux systems even.  Hope this helps.

+W
 

[jdetroullioud]

Will,

I use sudo because my scale is installed in the root directory. If I don't use sudo then the make and make install encounter errors.

Thank you for the source trick, I did not know that.

On the last point, I would like to make sure I understand well. "Shared build" means that the bins are automatically linked to the libraries I just compiled; hence I don't need to replace the original lib by these freshly compiled libraries. However, there is one point that confuses me. I suppose that the bins that are dynamically linked with the freshly compiled libraries are the one that are also created with the compilation within build, right? In other words, the build/install/bin are linked to the build/install/lib. The next step that I would take is then to actually replace the original bins in the Scale6.2/bin folder with these newly compiled bins. I am guessing that these new bins are still going to look at the right place to find their linked libraries (they will look into build). I am correct?

Secondly, what happens when only libs are compiled like in the case of  packagers/Origen/Manager/wrap ? Since I don't have new bins to replace the original ones with, nobody is going to pick up these libs... I would think that the original bins are still linked to the original libs. I guess the practical question I have is: once I compiled packagers/Origen/Manager/wrap and have the install/lib ready, what should I do to see the change I operated?

I am sorry for all these questions but I am a beginner in software engineering.

Thanks a lot for all the help.

Julien

[Will Wieselquist]

Julien,

Have a look at the "ldd" utility on linux. It outputs the libraries that an executable or other library is linked to.

For example:

ldd bin/origen

linux-vdso.so.1 =>  (0x00007fff3a3ff000)

libSequenceOrigen_origen.so.06 => /home02/ww5/work/testing/x/SCALE-6.2.1/bin/../lib/libSequenceOrigen_origen.so.06 (0x00002aeab3b41000)

libSequenceOrigen_SONInputLib.so.06 => /home02/ww5/work/testing/x/SCALE-6.2.1/bin/../lib/libSequenceOrigen_SONInputLib.so.06 (0x00002aeab3dae000)

libscalelib.so.06 => /home02/ww5/work/testing/x/SCALE-6.2.1/bin/../lib/libscalelib.so.06 (0x00002aeab3fb7000)

libScaleCell.so.06 => /home02/ww5/work/testing/x/SCALE-6.2.1/bin/../lib/libScaleCell.so.06 (0x00002aeab427c000)

libScaleInput_Parser.so.06 => /home02/ww5/work/testing/x/SCALE-6.2.1/bin/../lib/libScaleInput_Parser.so.06 (0x00002aeab44fd000)

I think first you should get a SCALE build working in your home directory or some place where you have complete control without using sudo. Once you are building SCALE locally in your home directory, any make -j8 install will create in your build/INSTALL directory, a completely independent SCALE build for your system. If you want to replace the existing SCALE with it, I would completely delete the existing SCALE install (except for the data directory) and replace it with yours.

+W

[jdetroullioud]

Will,


I might have found a way to fix the problem thanks to your advices.
I changed "-D BUILD_SHARED:BOOL=ON" to OFF, recompiled, put the new bin in the original scale and now the recompiled elements are looking at the right version of libstdc++.so.6 during run time. I added some prints in the source code depletion.f90 that actually were shown on the output file of my origin.inp test run. Looks like it is working with static libraries then.

Now, concerning the origin of the problem: during compilation, the bins and libs that were being recompiled were linked to the libstdc++.so.6 of my system in my usr/lib. This is also what I found out when I ldd them in my build/packages/bin or lib directory. However, when I put them into the original Scale6.2/bin folder, they were no longer looking at the right libstdc++.so.6 (usr/lib) but at the one in Scale6.2/lib (and I wonder why Scale would even have its own libstdc++.so.6). Something forces the bins in Scale6.2/bin to be linked with the wrong libstdc++.so.6.

Concerning your suggestion on how to use a totally new build, I am not sure I would want to do that. I basically want to recompile Origen source codes only. I can thus save time by just cd package/origen and recompile from there since I don't recompile everyone but only the source codes I actually touched. So I guess it's just a question of saving time. But I assume it is  the sage method; if something goes wrong at some point in my attempts to modified Origen, I might turn to your method.

Thanks a lot Will for your precious help.


Best,


Julien

[Will Wieselquist]

Okay, so we both learned something. I am guessing we have that libstdc++ in there in because we are trying to fix the C++ feature set at a particular version. Your compiler wants you to use a different version and there the mismatch happens. So here are your options in summary:

1. The static build approach for just ORIGEN, but it makes me a little uncomfortable having dependency on two versions of libstdc++ at once. 
2. If you recompiled everything once on your system, you could effectively "upgrade" it to your, single version of libstdc++. Then you could do what you were doing in the beginning and just update ORIGEN. 
3. Alternatively, you could delete libstdc++ from the SCALE lib directory and force everything in SCALE to use your system libstdc++. I think this would be my preference.
   

Julien, will you do me a favor and change the title of this case to more accurately reflect the issue. Something like "Conflicting libstdc++.so.6: versions of GLIBCXX when compiling ORIGEN from SCALE source with local modifications on Ubuntu Linux 16.0.4".

Best Regards,

Will

[jdetroullioud]

Will,


I changed the title.

Concerning your propositions: no. 2 makes sens to me now. That would be a way to have every bin/lib looking at the same libstdc++.so.6. I will do that if I have problems. For no.3, I am not sure if that would work; I did try previously to replace the Scale libstdc++ by a copy of my own system libstdc++, that did not work.

Thanks again.

Best,


Julien