Re: [moose-generic] MOOSE_installation_problem

[Subhasis R. <ray...@gm...>]

Hi,
Given you have a local python at:
/home/diag/opt/python2.7/

I assume that you also added
-L/home/diag/opt/python2.7/

in front of the PYTHON_LDFLAGS.
I found that libmkl_core.so provides functions for BLAS. Are you using a
GSL/CBLAS built with intel compiler? Also it might be worth double checking
that you run "make clean" before each new build. Beyond that I cannot see
any solution to the situation.

Best,
  Subha



On Tue, Apr 9, 2013 at 12:19 AM, Vadim A <ast...@nc...> wrote:

> Hi Subha.
>
> I try everything but still getting segmentation fault.
>
>
>
>   I am pointing to new "numpy" compiled with gnu
>
> export
> LD_LIBRARY_PATH=/home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages:$LD_LIBRARY_PATH
>
> and modified Makefile to point to the new lib:
>
> PYTHON_INCLUDES := -I/home/diag/opt/python2.7/include/python2.7
> -I/home/diag/opt/python2.7/include/python2.7
> -I/home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages/numpy/core/include/
>
>
>
>
> gdb shows me that new "gnulib" become used  but still segmentation foult
> from "libc.so"
>
>
> Reading symbols from /opt/*intel*/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so...(no
> debugging symbols found)...done.
> Loaded symbols for /opt/*intel*
> /Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so
> Reading symbols from
> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so...(no
> debugging symbols found)...done.
> Loaded symbols for
> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so
> ………
>
> Reading symbols from /home/diag/opt/python2.7/*gnulib*
> /lib/python2.7/site-packages/numpy/random/mtrand.so...done.
> Loaded symbols for /home/diag/opt/python2.7/*gnulib*
> /lib/python2.7/site-packages/numpy/random/mtrand.so
>
> …….
> Reading symbols from
> /home/diag/opt/python2.7/lib/python2.7/lib-dynload/_struct.so...done.
> Loaded symbols for
> /home/diag/opt/python2.7/lib/python2.7/lib-dynload/_struct.so
> Core was generated by `python'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x000000344be7275e in free () from /lib64/libc.so.6
>
>
>
>
>
>
> I see "intel" stuff and "gnulib"
>
>
>
>
>
> When I run "idd" on generated _moose.so
>
> it shows libraries where some "gnu" some "intel" which might be a reason
> for problem :
>
> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so
> (0x00002b1fa0b00000)
> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so
> (0x00002b1fa0eb3000)
> /opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5 (0x00002b1fa16c8000)
> /home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so
> (0x00002b1fa17ed000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b1fa1a43000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00002b1fa1c5f000)
> libutil.so.1 => /lib64/libutil.so.1 (0x00002b1fa1e63000)
> libpython2.7.so.1.0 => /home/diag/opt/python2.7/lib/libpython2.7.so.1.0
> (0x00002b1fa2066000)
> libgsl.so.0 => /home/diag/opt/gsl/1.15/gnu/lib/libgsl.so.0
> (0x00002b1fa243e000)
> libgslcblas.so.0 => /home/diag/opt/gsl/1.15/gnu/lib/libgslcblas.so.0
> (0x00002b1fa285e000)
> libm.so.6 => /lib64/libm.so.6 (0x00002b1fa2a97000)
> libstdc++.so.6 => /home/diag/opt/gcc/4.6.1/lib64/libstdc++.so.6
> (0x00002b1fa2d1b000)
> libgcc_s.so.1 => /home/diag/opt/gcc/4.6.1/lib64/libgcc_s.so.1
> (0x00002b1fa3020000)
> libc.so.6 => /lib64/libc.so.6 (0x00002b1fa3235000)
> libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00002b1fa358d000)
> libimf.so => /opt/intel/Compiler/11.1/072/lib/intel64/libimf.so
> (0x00002b1fa3868000)
> libsvml.so => /opt/intel/Compiler/11.1/072/lib/intel64/libsvml.so
> (0x00002b1fa3bfc000)
> libcxaguard.so.5 =>
> /opt/intel/Compiler/11.1/072/lib/intel64/libcxaguard.so.5
> (0x00002b1fa3e13000)
> libintlc.so.5 => /opt/intel/Compiler/11.1/072/lib/intel64/libintlc.so.5
> (0x00002b1fa3f14000)
> /lib64/ld-linux-x86-64.so.2 (0x000000344ba00000)
>
>
>
> I don't know what else we can do
>
> Regards,
>
> Vadim.
>
>
>
> On Apr 5, 2013, at 11:39 PM, Subhasis Ray wrote:
>
> Dear Vadim,
>  I am not familiar with such cluster environment. But from what I gather
> on the Internet, it seems that the issue is possibly a mismatch of
> compilers and libraries. If your default compiler is intel, then loading
> python before gnu perhaps loads a Python compiled with intel compiler your
> default. Can you see if changing the order of loading modules helps? i.e.
>
> module load gnu/4.6.1
> module load python
> ...
>
>
> Also, you can run `ldd` on generated _moose.so to list the linked
> libraries and add the paths to the directories containing those libraries
> to your LD_LIBRARY_PATH environment variable.
>
> hth,
>   Subha
>
>
>
>
> On Sat, Apr 6, 2013 at 12:35 AM, Vadim A <ast...@nc...> wrote:
>
>> Hi,
>>
>> numpy has been compiled with gnu on our cluster and to access bumpy  we
>> do the following:
>>
>> module load python
>> module load gnu/4.6.1
>> export
>>
>> PYTHONPATH=/home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages:$PYT
>> HONPATH
>>
>>
>>
>> Should I also adjust   Makefile for MOOSE  to make sure that proper
>> "numpy" library will be used during compilation step ?
>>
>> Thanks a lot in advance for information.
>>
>> Vadim.
>>
>>
>>
>>
>> On Mar 28, 2013, at 2:13 AM, Subhasis Ray wrote:
>>
>> > First please confirm that Python and numpy were also compiled with gcc.
>> >
>> > If so, then best option could be to allow somebody from here (niraj or
>> > me) to login to your system (via some portal as Amitava mentioned
>> > earlier in this thread) and run gdb as we cannot reproduce the error
>> > on our system.
>> >
>> > On 3/28/13, Vadim A <ast...@nc...> wrote:
>> >>
>> >>
>> >> On Mar 28, 2013, at 12:15 AM, Subhasis Ray wrote:
>> >>
>> >>> Hi,
>> >>> On 3/28/13, Vadim A <ast...@nc...> wrote:
>> >>>> When I compile, I always see lines with g++
>> >>>>
>> >>>>
>> >>>> g++ -g -pthread -fpermissive -fno-strict-aliasing -fPIC
>> >>>> -fno-inline-functions -Wall -Wno-long-long -pedantic -DDO_UNIT_TESTS
>> >>>> -DUSE_GENESIS_PARSER -DSVN_REVISION=\"4401M\" -DLINUX -DUSE_GSL -I
>> >>>> /home/diag/opt/gsl/1.15/gnu/include/    basecode/_basecode.o
>> msg/_msg.o
>> >>>> shell/_shell.o biophysics/_biophysics.o hsolve/_hsolve.o
>> >>>> randnum/_randnum.o
>> >>>> scheduling/_scheduling.o builtins/_builtins.o device/_device.o
>> >>>> kinetics/_kinetics.o ksolve/_ksolve.o regressionTests/_rt.o
>> >>>> utility/_utility.o geom/_geom.o mesh/_mesh.o manager/_manager.o
>> >>>> signeur/_signeur.o     -L/usr/lib -L/usr/local/lib -lpthread -L/lib64
>> >>>> -L/usr/lib64 -L/usr/lib -L/home/diag/opt/gsl/1.15/gnu/lib/ -lgsl
>> >>>> -lgslcblas
>> >>>> -lm -o moose
>> >>>>
>> >>>>
>> >>>>
>> >>>> That tells me that I am using g++ (which is gcc) but not Intel
>> compiler,
>> >>>> right ?
>> >>>
>> >>> Yes, moose is being compiled by g++
>> >>>
>> >>>>
>> >>>> So, I kind of confused what should I do here.
>> >>>>
>> >>>
>> >>> But what about Python libs? In your previous mail
>> >>>
>> >>> ----8<----------------->8---
>> >>> gdb -c core.8851 /home/diag/opt/python2.7/bin/python
>> >>>
>> >>> Reading symbols from
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so...(no
>> >>> debugging symbols found)...done.
>> >>> Loaded symbols for
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so
>> >>> Reading symbols from
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so...(no
>> >>> debugging symbols found)...done.
>> >>> Loaded symbols for
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so
>> >>> Reading symbols from
>> >>> /opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5...(no debugging
>> >>> symbols found)...done.
>> >>> Loaded symbols for
>> /opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5
>> >>> Reading symbols from
>> >>>
>> /home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so...(no
>> >>> debugging symbols found)...done.
>> >>> Loaded symbols for
>> >>>
>> /home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so
>> >>> Reading symbols from
>> >>> /home/diag/opt/python2.7/lib/libpython2.7.so.1.0...done.
>> >>> Loaded symbols for /home/diag/opt/python2.7/lib/libpython2.7.so.1.0
>> >>>
>> >>> ----8<----------------->8---
>> >>>
>> >>> shows that several libraries from intel compiler are being loaded
>> >>> before scipy/sparse/sparsetools/_coo.so and libpython2.7.so.
>> >>>
>> >>> Did you compile Python in
>> >>> /home/diag/opt/python2.7/lib/libpython2.7.so.1.0 and/or numpy/scipy
>> >>> from source? In that case, did you use intel compiler to compile them?
>> >>>
>> >>> Though this could be red herring, I do not see any reason for the
>> >>> control to reach basecode/SetGet.h:289. May be a debugging session
>> >>> could help.
>> >>>
>> >>> Best,
>> >>>  Subha
>> >>>
>> >>
>> >>
>> >
>>
>>
>
>