IFC and Redhat 9

[jl_wu]

Hi,

I just upgrade to RedHat 9 and try to compile my fortran stuff with Intel Fortran Compiler 7.1. But I got some error message as:

my_intel_location/compiler70/ia32/lib/libIEPCF90.a(f90fioerr.o)(.text+0x4d3): In function `f_f77ioerr':
: undefined reference to `__ctype_b'

What's the problem?

jl_wu

[Intel_C_Intel]

> Hi,
>
> I just upgrade to RedHat 9 and try to compile my
> fortran stuff with Intel Fortran Compiler 7.1. But I
> got some error message as:
>
> my_intel_location/compiler70/ia32/lib/libIEPCF90.a(f90
> ioerr.o)(.text+0x4d3): In function `f_f77ioerr':
> : undefined reference to `__ctype_b'
>
> What's the problem?
>
> jl_wu

Hi,

This might be completely unrelated but I had the same messages a few days back but I was running RH8.0 - But I had just upgraded the glibc to 2.3.2 as compared to the latest patch which only supports 2.2.94 ? So I'd hesistate a guess and say it is related to glibc .

Cheers,

John

[Steven_L_Intel1]

We just get RH8 support out the door and they spring RH9 on us! It looks, unfortunately, as you should expect to have such problems each time RH releases a new version with a new, incompatible glibc. I don't know of immediate plans to add RH9 support - I suggest you back off to RH8 and wait until we release a version that supports RH9, which may not be until late this year.

Steve

[klancek]

Is it possible to install/compile the older, compatible glibc for exclusive for use by ifc? For example, install it in /opt/old_glibc/ ? How does ifc find the files it needs from glibc--is it simply a matter of setting the a proper path in my .bashrc? .. this fix would definitely be easier than a "downgrade" to red hat linux 8.0!! Thanks -Lance

[geoff_leach]

Summary:

ifc 7.0 and 7.1 work for me on RH8.0 with glibc 2.3.2.

Details:

I'm running RH8.0 with up2date's (although no up2date for the last week or so when redhat's servers have been busy). glibc 2.3.2 came through as a security fix a few weeks ago (I think).

I've been using ifc 7.0 heavily, including idb, for the last couple of weeks under RH8.0/glibc2.3.2. I've just installed ifc 7.1 and it also works for me, including idb, although my testing has been limited at this point.

Geoff

[Steven_L_Intel1]

Lance, I don't know the answer to your question. I am not yet very knowledgeable about Linux. I would suggest, though, that a reading of the User's Guide would tell you how the libraries are found - it may well be that supplying a private copy of the older glibc would help.

Steve

[klancek]

Hey thanks for the input Geoff and Steve.

Geoff: exactly what rpm of glibc do you have? To check I use: % rpm -q glibc ..mine is glibc-2.3.2-11.9 It might help me understand what the big difference is.

Steve: I will try it out, should I have success I'll post again, thanks

[geoff_leach]

localhost% rpm -q glibc
glibc-2.3.2-4.80

I also did a little googling, searching on

undefined reference to `__ctype_b'

turns up glibc issues from last year, but I couldnt see anything new regarding RH9.

Can confirm ifc 7.1 Build 20030327Z from l_fc_pu_7.1.011.tar from premier.intel.com has been working (well) for me on RH8 with glibc-2.3.2-4.80. I've been using it today, along with idb (looking for an energy leak in the molecular dynamics code I'm working on).

We (well josepha actually) hope to try ifc 7.1 Build 20030327Z under RH9 to compile up MPICH some time today.

[Intel_C_Intel]

Lance,

I upgraded to RedHat 9 two days ago and I'm getting the same problems with ifc. I'm running with glibc-2.3.2-27.9 and Intel Fortran Compiler Version 7.1 Build 20030307Z.

Andrew

[jl_wu]

Hi,

I have patched the file "/usr/include/bits/statfs.h" by put
"# define __SWORD_TYPE int" in line 25.

It will look like:

.....

Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */

#ifndef _SYS_STATFS_H
# error "Never include directly; use instead."
#endif

#include

# define __SWORD_TYPE int
struct statfs
{
.....

IFC, ICC and MPICH could be compiled together. But the MPICH doesn't work properly. MPICH won't install "mpif77" and "mpif90".

jl_wu

[Intel_C_Intel]

Hi,

Just checking that I understand what you're suggesting here. I modified the file /usr/include/bits/statfs.h by adding in the extra line as you suggested. Do I then need to completely recompile ifc (can I just reinstall from the usual set of rpm's that I downloaded from Intel?).

Thanks,
Andrew

[beregond]

The following worked for me. First I copied the file /lib/libc-2.2.93.so from an old RH80 system to a directory not in the library path of my new RH90 system. Then I linked against this library manually by adding the compiler option -lc-2.2.93.

Not an elegant solution, but it worked for me...

[klancek]

beregond: thanks!

Sorry, I'm still learning about paths, to clarify: Your libc-2.2.93, is it now in your user path, or must it be in the directory where you call ifc? Also, I'm curious, where or how is the library path defined?

I tried something similar with the -L/new_lib_dir/ but I must have flubbed it up somehow, same error. -Lance

[Intel_C_Intel]

beregond's solution seems to be working for me. I copied libc-2.3.2 (also from a RedHat 8 distribution) into /opt/old_lib/ and added the following to the compiler options: -L/opt/old_lib -lc-2.3.2

Andrew.

P.S. I *think* that the library path is defined by LD_LIBRARY_PATH, but I'm not 100% sure......

[klancek]

Thanks Andrew, I was just going to report same thing using libc-2.2.5 (from a 7.3 distribution), which also worked. I added the following line to my .bashrc:

alias ifc='ifc -w95 -w90 -cm -L/opt/intel/old_glibc_libs -lc-2.2.5'

For the curious, I run glibc-2.3.2-27.9 but I think this fix is general.

[ivica_jan]

Well, I am a one with RH9, because my new hardware is supported BUT ifc is giving me trouble...
I did all you suggested; copied old libc (2.2.5) to /opt/old_lib and after that ifc is not complaining about erros but in that way I can ONLY compile "dynamic"....
but my source have static allocation
and I HAVE TO USE -static option and after that I got message like:"
ld: cannot find -lc-2.2.5

any hint?
btw rpm -qi libc
gives me a lots of other libs like /lib/libpthread-0.9.so or libcompat .. what about them?

Cheers, Thanks in advance Ivica

[sfuniroma2]

> Well, I am a one with RH9, because my new hardware is
> supported BUT ifc is giving me trouble...
> and I HAVE TO USE -static option and after that I got
> message like:"
> ld: cannot find -lc-2.2.5
>
> any hint?
Did you try changing /etc/ld.so.config and then rerun ldconfig ?

> btw rpm -qi libc
> gives me a lots of other libs like
> /lib/libpthread-0.9.so or libcompat .. what about
> them?
>

If I remember correctly, the main reason for the new glibc/kernel in RH 9.0 was to provide a new implementation of threads, done by someone at RH, which improves threads performance a lot, but is not scheduled to be in the stable kernels until 2.6.

Salvatore Filippone

[klancek]

If it's a allocation bug, have you tried -save or -Bstatic? They seem to be different from -static. Check out /opt/intel/compiler70/docs/for_ug_lnx.pdf cheers

[mcelrath]

Fix #1: recompile glibc. Here is a patch which will fix the __ctype_b problem: http://gd.tuwien.ac.at/opsys/linux/lunar/patches/glibc-2.3.2-ctype-compat.patch

Apparently this will not hurt anything, but is not technically correct, so won't go into the distributed glibc's.

Note this *only* works to solve the __ctype_b error. If that's the only error your code gives, than this workaround should be fine. If your code uses ifc and pthreads, see fix #2. Also note that I have code that still exhibits the __ctype_b error after fix #1. (it's some f90 that also complains about pthread functions)

Fix #2: it seems to cause no problem to downgrade to the RH8 glibc (and only glibc -- rest of system is RH9). I installed the latest version available, glibc-2.3.2-4.80.6 from redhat's 8.0 update directory. Make sure to upgrade glibc-* and nscd as well. MAKE SURE that you do not download both the i386 and i686 version of glibc and then do an 'rpm -U *'. This can leave your system in an unusable state!!! (all programs will segfault) Make sure you have only ONE glibc-2.3.2 rpm in the command line to rpm -U. You will have to use the --oldpackage option with rpm to do this.

With fix #2 you can also compile programs that give linker errors about pthread functions, but you must add to your command line '-lIEPCF90 -lpthread' when linking. (Before this was not necessary) It is the ifc library libIEPCF90 that requires pthreads for some reason. This changes the linking order so that the ifc library libIEPCF90 is linked earlier. Normally (i think) it would be linked last, and thus causes errors with unresolved pthread functions. I do not know what it is in the programs I am compiling which requires libIEPCF90 or pthreads (this is not my code), it looks like straight fortran 90 to me. A simple 'hello world' in fortran 90 does not seem to require the above linker options (so perhaps not all f90 programs will require -lIEPCF90 -lpthread).

Let's hope the Intel guys are on the ball and can put out ifc 7.2 soon. Can anyone at Intel comment on how difficult it is to make the transition to the new thread library (NTPL)?

If anyone else has successes or failures with either of these methods, please post here. I'd like to know.

-- Bob

[ivica_jan]

Thnks mcelrath!
When I use switch -lIEPCF90 -lpthread all error messages conceranin threads are gone... there is only ctype error left! So you suggest to applay patch and recompile glibc..
I have rpm binary so I have to download source first?
and how to apply patch??
give me some hint, comandline how and where to put that patch....
Thanks in advance!
cheers, Ivica!

[ivica_jan]

Well my ifc have this switch :
-tpp7 -mp -save -Bstatic -132 -vms -zero -v -lIEPCF90 -lpthread

and here is error mesage:
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xaa): In function `libi_exit':
: undefined reference to `pthread_self'
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb6): In function `libi_exit':
: undefined reference to `pthread_equal'
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread':
: undefined reference to `pthread_exit'
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex':
: undefined reference to `pthread_mutex_unlock'
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init':
: undefined reference to `pthread_self'
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(f90fioerr.o)(.text+0x4d3): In function `f_f77ioerr':
: undefined reference to `__ctype_b'
/opt/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x7d): In function `std::set_unexpected(void (*)())':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x95): In function `std::set_unexpected(void (*)())':
: undefined reference to `pthread_mutex_unlock'
/opt/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x107): In function `std::set_terminate(void (*)())':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x11f): In function `std::set_terminate(void (*)())':
: undefined reference to `pthread_mutex_unlock'
/opt/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())':: undefined reference to `pthread_mutex_unlock'
/opt/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock':
: undefined reference to `pthread_mutex_unlock'
/opt/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2':
: undefined reference to `pthread_mutex_unlock'



hope that this help a bit more ...
Cheers, IVica