[FLASH-USERS] Compiling problem on SL6

[Seyit Hocuk]

Hi again, Chris and community,

The problem is solved.

You were pointing me in the right direction, Chris, and I was on the 
same track as well without realizing. Apparantly, I still require 32-bit 
version of glibc, i.e., "/usr/lib/crt1.o" instead of 
"/usr/lib64/crt1.o". Although I don't understand why I require a 32-bit 
version, since everything is built one a 64-bit machine with 64-bit 
environment, installing this (i.e., glibc-dev i guess) solved the issue. 
I think the problem might be related to ifort. I have ifort version 
10.1.017 and when installing ifort, you have the option of 32-bit 
version and 64-bit version (fc and fce). The curious thing is that even 
the 64-bit version of ifort actually is a 32-bit version if I look close 
enough and requires 32-bit dependencies.

Long story short, it works now, and thanks for pointing me toward the 
right direction.

Kind regards,
Seyit






On 11/29/2011 11:47 AM, Seyit Hocuk wrote:
> Hi Chris,
>
> Thanks for replying. No I hadn't solved the problem yet. I was 
> thinking it is a linking problem and might be that an additional flag 
> was required for linking in SL6 , although, I did not have any success 
> yet. I never thought of glibc. I don't have static in FLASH link 
> options (in Makefile.h), but I don't know how glibc it is built on my 
> system.
>
> "$ repoquery --list glibc-static" gives me this
> /usr/lib/libBrokenLocale.a
> /usr/lib/libanl.a
> /usr/lib/libc.a
> /usr/lib/libc_stubs.a
> /usr/lib/libcrypt.a
> /usr/lib/libdl.a
> /usr/lib/libm.a
> /usr/lib/libnsl.a
> /usr/lib/libpthread.a
> /usr/lib/libresolv.a
> /usr/lib/librt.a
> /usr/lib/libutil.a
> /usr/lib64/libBrokenLocale.a
> /usr/lib64/libanl.a
> /usr/lib64/libc.a
> /usr/lib64/libc_stubs.a
> /usr/lib64/libcrypt.a
> /usr/lib64/libdl.a
> /usr/lib64/libm.a
> /usr/lib64/libnsl.a
> /usr/lib64/libpthread.a
> /usr/lib64/libresolv.a
> /usr/lib64/librt.a
> /usr/lib64/libutil.a
>
> while "$ repoquery --list glibc-static" returns me nothing on Cenos5 
> (I still have a machine with Centos5 where I can test things). Could 
> it be that I use glibc-static unintentionally instead of the normal 
> glibc? Perhaps I can set this in the Makefile.h.
>
> On an another note, +noio option still fails and gives the same error. 
> That is,
>>
> /net/ulubey/data/users/seyit/programmas/Libraries/lib64/mpich2-1.0.7/MPICH2/lib 
>  -lmpich
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/crt1.o: In
> function `_start':
>> (.text+0x12): undefined reference to `__libc_csu_fini' ... etc
>
>
> Kind regards,
> Seyit
>
> ps: Could the error possibly be due to the wrong elf-class? The first 
> file that the error shows is "/usr/lib64/crt1.o". On my old system, I 
> also had the 32-bit version of this file "/usr/lib/crt1.o". Were I 
> somehow using the 32-bit version then? I wish there was a way to 
> confirm this.
>
>
>
> On 11/29/2011 12:17 AM, Christopher Daley wrote:
>> Hi Seyit,
>>
>> Did you ever resolve this problem?
>>
>>
>> These symbols exist in libpthread and libc.  Perhaps you are trying to
>> link statically and have not yet installed a static glibc for you
>> clean Scientific-Linux 6 installation:
>>
>> $ repoquery --list glibc-static
>> /usr/lib64/libBrokenLocale.a
>> /usr/lib64/libanl.a
>> /usr/lib64/libc.a
>> /usr/lib64/libc_stubs.a
>> /usr/lib64/libcrypt.a
>> /usr/lib64/libdl.a
>> /usr/lib64/libm.a
>> /usr/lib64/libnsl.a
>> /usr/lib64/libpthread.a
>> /usr/lib64/libresolv.a
>> /usr/lib64/librt.a
>> /usr/lib64/libutil.a
>>
>> If so, try installing the glibc-static package or remove the -static
>> option from your FLASH link options.
>>
>>
>> If the link still fails then you should test if it fails when you
>> remove the FLASH I/O library dependence, i.e. setup FLASH with +noio.
>>
>> Chris
>>
>>
>> On 11/18/2011 05:06 AM, Seyit Hocuk wrote:
>>> Dear all,
>>>
>>> I have recently switched to Scientific Linux 6 (from CenOS 5), but 
>>> now I
>>> cannot compile my code anymore. Below is a snippet of the error. It
>>> happens during the linking stage. Can anyone comment on this?
>>>
>>> I use my own fortran compiler (ifort 10.1.017)
>>> I use my own mpich (2.1.0.7)
>>> I use hdf5 version 1.8.1 (with api bindings for 1.6)
>>> These libraries are unchanged from Centos5 to SL6.
>>>
>>> I use the systems default gcc, which has changed from C5 to SL6.
>>>
>>> I've tried to reinstall ifort and mpich, even tried to use intelcc
>>> instead of gcc, but compiling still goes wrong. The problem lies surely
>>> in one of these. Is it gcc, mpich, or hdf5?
>>>
>>> Kind regards,
>>> Seyit
>>>
>>>
>>>
>>> ......tree.o umap.o user_coord_transfm.o ut_conversionInterface.o
>>> ut_convertToArrayIndicies.o ut_convertToMemoryOffset.o ut_fndpos.o
>>> ut_hunt.o ut_interpolationInterface.o ut_polint.o 
>>> ut_quadraticInterpol.o
>>> ut_sortInterface.o ut_sortOnProcs.o workspace.o
>>> -L/net/ulubey/data/users/seyit/programmas/Libraries/lib64/hdf5-1.8.1/hdf5/lib 
>>>
>>>
>>> -lhdf5 -lz -L
>>> /net/ulubey/data/users/seyit/programmas/Libraries/lib64/mpich2-1.0.7/MPICH2/lib 
>>>
>>>
>>> -lmpich
>>>
>>> /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/crt1.o: In
>>> function `_start':
>>> (.text+0x12): undefined reference to `__libc_csu_fini'
>>> /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/crt1.o: In
>>> function `_start':
>>> (.text+0x19): undefined reference to `__libc_csu_init'
>>> /net/ulubey/data/users/seyit/programmas/Libraries/lib64/mpich2-1.0.7/MPICH2/lib/libmpich.a(abort.o): 
>>>
>>>
>>> In function `MPI_Abort':
>>> abort.c:(.text+0x22a): undefined reference to `pthread_getspecific'
>>> abort.c:(.text+0x25a): undefined reference to `pthread_getspecific'
>>> abort.c:(.text+0x369): undefined reference to `pthread_setspecific'
>>> abort.c:(.text+0x3ae): undefined reference to `pthread_setspecific'
>>> /net/ulubey/data/users/seyit/programmas/Libraries/lib64/mpich2-1.0.7/MPICH2/lib/libmpich.a(initthread.o): 
>>>
>>>
>>> In function `MPIR_Init_thread':
>>> initthread.c:(.text+0x32e): undefined reference to 
>>> `pthread_getspecific'
>>> initthread.c:(.text+0x354): undefined reference to 
>>> `pthread_setspecific'
>>> /net/ulubey/data/users/seyit/programmas/Libraries/lib64/mpich2-1.0.7/MPICH2/lib/libmpich.a(initthread.o): 
>>>
>>>
>>> In function `MPI_Init_thread':
>>> initthread.c:(.text+0x3fa): undefined reference to `pthread_key_create'
>>> initthread.c:(.text+0x4d9): undefined reference to `pthread_key_delete'
>>> initthread.c:(.text+0x517): undefined reference to 
>>> `pthread_getspecific'
>>> initthread.c:(.text+0x543): undefined reference to 
>>> `pthread_setspecific'
>>> initthread.c:(.text+0x567): undefined reference to 
>>> `pthread_getspecific'
>>> initthread.c:(.text+0x593): undefined reference to 
>>> `pthread_setspecific'
>>> initthread.c:(.text+0x5bf): undefined reference to 
>>> `pthread_getspecific'
>>> initthread.c:(.text+0x5dc): undefined reference to 
>>> `pthread_setspecific'
>>> initthread.c:(.text+0x5ec): undefined reference to 
>>> `pthread_getspecific'
>>> initthread.c:(.text+0x618): undefined reference to 
>>> `pthread_setspecific'
>>> initthread.c:(.text+0x63d): undefined reference to `pthread_setspecific
>>> .... etc. etc.
>>
>