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

[Martyn_C_Intel]

Unfortunately, there's much more to RH9 compatibility than the ctype_b issue discussed above. In particular, there's a major change in the pthreads implementation. It's hoped to support RH9 in the next major compiler version, but release of that is a few months away.

Martyn

[Martyn_C_Intel]

There's an ifc.cfg file in the compiler70/ia32/bin directory that can be used to change compiler default options.

Martyn

[winfrid_tschiedel]

There is a very simple solution to bypass the problem

use for link : ifc -i_dynamic

[kolli]

Hi

I tried this simple solution; the compilation proceeded okay, but I get errors at run-time (see below). Any clues how to work around this problem ?

Thanks,
Kumar.

$>ifc -i_dynamic topo-sasia-subset.f
main program

9 Lines Compiled
$>a.out
a.out: relocation error: /opt/intel/compiler70/ia32/lib/libIEPCF90.so.3: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

[leightsai]

I did that but when I ran 'ifc' on the command it gave me:
/usr/lib/crt1.o(.text+0x18): In function `_start':
../sysdeps/i386/elf/start.S:77: undefined reference to `main'
any idea?
Thanks.
Leigh

[pmacinnis]

Here is our solution to run 7.1 on RH9 that works for
both the pthread and the libc problems.

Since programs that are compiled and linked on RH8 do run
on RH9, we tried to re-create a RH8 environment on RH9.

We copied the 2 directories /usr/lib and /lib from RH8
and put them on RH9 in /opt/intel/rh8.

Next we get the Linux linker ld to use these files in
preference to those in RH9's /usr/lib/ and /lib/. There
are several files required in addition to the libc and
pthread already discussed ... crt1.o, crtn.o, ...

To do this we wrote a shell script that we insert
between the Intel compiler and the Linux linker that
prepends all references to /usr/lib with /opt/intel/rh8 -
giving /opt/intel/rh8/usr/lib/. We do the similar
thing for references to /lib/.

This seems to work. We tested using a large OpenMP
program that now compiles, links and runs fine on RH9.
The output matches what we get on an RH8 system and
what we get on an IBM RS6000. We have been using this
patch with various other programs for several weeks
without problems.

To compile using the full RH8 environment described
above requires this option on your ifc line:
@/opt/intel/rh8/rh8_env
e.g. ifc @/opt/intel/rh8/rh8_env -o hellow hellow.f

Note, this option can be inserted into a makefile and
forgotten. When Intel releases the updated Fortran
compiler for RH9, just drop the @ option described above.

Here are the 2 files that you need:
1. A 1 line compiler response file
(named /opt/intel/rh8/rh8_env):
-static -Qlocation,link,/opt/intel/rh8

2. The script that does the prepends
(named /opt/intel/rh8/ld). Make sure it's
executable by all - chmod a+x.
X---- CUT ------------------------------------------X
#!/bin/sh
#
# script to implement an RH8 environment on RH9 for
# Intel Fortran V7.1
#
# this script runs between the ifc compiler and the
# Linux loader LD
#
# it is invoked using the ifc option:
# -Qlocation,link,
#
# each reference to /usr or /lib is prepended with a
# reference to a directory where the equivalent RH8
# directories have been stored; then the real ld is
# invoked
#
RH8_PREFIX=/opt/intel/rh8
RH8_LD_TMP=$USER.tmp

echo "ld " >$RH8_LD_TMP
for i; do
if echo $i | /bin/egrep -q "^/usr/"
then
echo "$RH8_PREFIX$i " >> $RH8_LD_TMP
else
if echo $i | /bin/egrep -q "^/lib/"
then
echo "$RH8_PREFIX$i " >> $RH8_LD_TMP
else
if echo $i | /bin/egrep -q "^-L/usr/"
then
echo "-L$RH8_PREFIX${i:2} " >> $RH8_LD_TMP
else
if echo $i | /bin/egrep -q "^-L/lib/"
then
echo "-L$RH8_PREFIX${i:2} " >> $RH8_LD_TMP
else
echo "$i " >> $RH8_LD_TMP
fi
fi
fi
fi ; done
echo " " >> $RH8_LD_TMP
. ./$RH8_LD_TMP
X-------CUT ----------------------------------------X

Note, the actual ld command used (after prepends) is
left in file $USER.tmp but this file usually can't be
used alone because it often references /tmp files
created and deleted by the compiler.

Hope this helps.

[garoldm]

Hi,


Following the advice of pmacinnis, I created an RH8 environment for linking to ifc 7.1 programs (on my Xeon RH9 machine) exactly as pmacinnis recommended: I copied (up2date-ed) /usr/lib and /lib from my laptop (RH8) and used the definitions and script that pmacinnis provided. Yet when I tried to compile hello.f I got the following errors:


% ifc @/home2/garold/opt/intel/rh8/rh8_env -o hello hello.f
program HELLO

6 Lines Compiled
/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/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'
%


The temporary file produced by the linker displayed the following:


ld
/home2/garold/opt/intel/rh8/usr/lib/crt1.o
/home2/garold/opt/intel/rh8/usr/lib/crti.o
/opt/intel/compiler70/ia32/lib/crtxi.o
-static
-u
___get_intrinsics
-o
hello
-rpath
/opt/intel/compiler70/ia32/lib
/tmp/ifcRDFePa.o
-Qy
-L/opt/intel/compiler70/ia32/lib
- L/home2/garold/opt/intel/rh8/usr/lib
-lintrins
-lIEPCF90
-lF90
-lintrins
-limf
-lm
-lirc
-lcxa
-lunwind
-lc
/opt/intel/compiler70/ia32/lib/crtxn.o
/home2/garold/opt/intel/rh8/usr/lib/crtn.o


(Note that I installed the rh8 environment in /home2/garold/opt/intel/rh8; this is consistent with script and the "@" flag to the ifc command.)


What is going wrong?


Thank you.

[pmacinnis]

Hi 'garoldm'

You are almost there!

I think you need to add the compiler switches -openmp and
-fpp2 to your ifc line. I need these switches whenever I compile
an OpenMP (i.e. pthread) program.

My .tmp file is just like yours except I have 2 extra lines
near the end, between the -lunwind and the -lc lines:
-lunwind
-lguide
-lpthread
-lc

These extra lines seem to get generated by the compiler
when you use -openmp switch.

I suppose you could as well add these libraries yourself
on the ifc line but I didn't need to.

I hope this works for you because I'm off starting tomorrow
for a week.

Paul

[Roland_Krause]

Paul,
two questions.

First. Shouldnt I be able to link against the old Redhat libraries and simply set LD_PRELOAD to ensure the correct old libraries are loaded? I have tried this but the resulting code does not run. As soon as the code enters the OpenMP stages there is an error message saying:

system error(1): __kmp_create_monitor: pthread_create Operation not permitted
abort: fatal problem

Second: When I initially ran the same code linked against the old libraries but at runtime dynamicaly linked against the new libraries, I was able to run the code for about 20 hours when it suddenly hung and stopped respoding alltogether. When I attached the debugger to it, all I could find out was that it was somewhere in libc dealing with threads and mutexes. Unfortunately I dont have the backtrace anymore and the executable is compiled with optimization on. So my question is: Is this approach really of industry strength? Do you have experience with running very large OpenMP simulations with this approach?

I am greatful for any input in this matter, since I am now considering to downgrade my cluster.


Roland

[pmacinnis]

Hi Roland,

We've found that old libraries and new libraries shouldn't be mixed.

Using ifc on RH9 it's not easy to 'link against the old libraries'. This is because there are library references that you are not aware of being generated by ifc and by the libraries themselves.

The solution that I described in a previous message lets all library references be generated but makes sure that all references are resolved by the old libraries. And static linking is used so no other libraries are introduced at run time.

Using LD_PRELOAD is problematic because the user is generally not aware of all libraries the must be preloaded. The system then ends up loading new libraries to satisfy remaining unresolved references and so you get a mix of old and new libraries which leads to trouble. We looked at the LD_PRELOAD solution but we decided that it requires too much insight and library fiddling for general use, and it must be cancelled immediately after the program is run or normal system utilities won't run.

If your question is 'is our solution industrial strength?': I've run a large OpenMP program for several hours on a 3GHz Xeon P4 using hyperthreading (4 threads) without problem. We've been running our cluster (30 nodes) heavily for about 5 weeks now without a single problem! Most programs are still single processor, are written in Fortran and run for several days.

Before you decide to downgrade your cluster, I think you should give our solution a try. If you have access to a RH8 system it shouldn't take more than an hour to set things up and it won't interfere with other programs and users. Then try your 20+ hour OpenMP program again. If it doesn't work you, you won't have invested a lot of time in it; if it works, you may have saved yourself a lot.

Paul

[Intel_C_Intel]

hi i used to run my code perfectly on comaq fortran on both windows and rh linux kernel 2.2.19-1.1qsw (on an alpha).
But when i tried it on my pc (p4) it refused to compile with the error mentioned at the begining of this thread. Then i used the dynamic intel library and it solved the problem, but there was no runtime error. All was going well when i noticed one of my out put files was growing at about 10Mb/s !, it was computing wrongly!!
so after much hedache i used interprocedural optimisation and it solved all proplems, but i noticed after two days run, every output file was OK except, one which was giving highly controvosial results!, any way it is about 45% than windows with CVF!!, if only it will compute correctly. Please help if any one has any ideas!! thanks!

[meikkel]

Hi all,

I have followed your instructions and recreated the RedHat 8 library environment on RedHat 9. Everything works fine in terms of compiling, linking etc. however despite -static the compiled executables apparently look for libc.so.6. I get the error message
cannot handle file 'libc.so.6' with TLS data
unless I use LD_LIBRARY_PATH to force it to look for
the RH8 libraries. This does not happen with a simple hello world program. Why would that be?
Now, this would not be a problem if I was just running
on one machine. However, I am planning to take the compiled binaries and run them on other RH9 systems
(where the RH8 libraries aren't installed). Any ideas
how to get rid of that inconvenience and create truly
static executables?

Or even better, when is Intel coming out with a fix for
RH9? It seems like it has been a while ...

Thanks.

[Brandon_H_Intel]

All,

Please download the latest 7.1 compiler from Intel Premier Support (https://premier.intel.com/). This compiler supports glibc 2.3.2. If you have a current license with valid support services, you can install this update. If you need to purchase a new license or renew your support services, please go to the Intel Software Development Products web page at http://developer.intel.com/software/products. Please try this compiler with your application and reopen this issue or create a new issue if you still see a problem.

Thank you,

Brandon
Intel Developer Support

Message Edited by intel.software.network.support on 12-09-2005 04:14 PM

[Brandon_H_Intel]

Ack! The dangers of canned messages (actually this has turned into a canned message itself :) ). Ignore the last part about issues. Sorry about that.

Brandon
Intel Developer Support

Message Edited by intel.software.network.support on 12-09-2005 04:13 PM

[neuberg]

I upgraded with l_fc_pc_7.1.033.tar and the problem encountered
with hello.f has disappeared. However, compilation with the -static
option (a way to get around problems using static arrays larger than 1 GB, that used to work with RedHat 8.0 and earlier) still does
not work. The installer does not mention explicit compatibility with glibc 2.3.2, and sticks to only mentioning glibc 2.2... versions.
HN.

[Brandon_H_Intel]

Neuberg, what problems are you having with -static? The installation not being updated to recognize glibc 2.3 is a known issue that is being worked.

Brandon
Intel DeveloperSupport

For on-line assistance: http://support.intel.com/support/performancetools
For user forums: http://intel.com/ids/community
For product support information: http://www.intel.com/software/products/support
* Intel and Pentium are registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries
* Other names and brands may be claimed as the property of others

Message Edited by intel.software.network.support on 12-09-2005 04:15 PM

[ivica_jan]

Is ifc now supporting RedHat9.0?
and if does what (where) is version available for
download?
I fonund only "old" version of ifc
Intel Fortran Compiler for Linux*

File Name/Size: l_fc_p_7.1.008.tar
83005440 bytes

[Steven_L_Intel1]

The new version is available only to those with support. The free version will get updated when version 8.0 ships.

Steve

[neuberg]

Hi,

I have a f77 code which runs with the most recent
ifc 7.1 on RH 9.0, so long as arrays add up to something
less than about 1GB. To go over that, in older versions of RH,
one needed to link statically. With RH9,
this last step does not work. (One still can around the
problem using dynamical common for the
large arrays, which was, and still is,
yet another alternative to get
around the 1GB barrier).

I compile with:

ifc -static -Vaxlib -tpp7 -xW -w

and get:


/opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit':
: undefined reference to `pthread_self'
/opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): 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/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())':
: undefined reference to `pthread_mutex_unlock'
/opt/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())':
: undefined reference to `pthread_mutex_lock'
/opt/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): 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'

I would get no such messages if I omitted -static.

Thanks,
HN

[Brandon_H_Intel]

Just to follow up on one of the issues here, the problem where the installation complained about glibc 2.3 not being supported is fixed in the latest compiler (l_fc_pc_7.1.035 for Fortran). You can get it at the Intel Premier Support web site.

Brandon
Intel DeveloperSupport

For on-line assistance: http://support.intel.com/support/performancetools
For user forums: http://intel.com/ids/community
For product support information: http://www.intel.com/software/products/support
* Intel and Pentium are registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries
* Other names and brands may be claimed as the property of others

Message Edited by intel.software.network.support on 12-09-2005 04:16 PM