IFC and Redhat 9

IFC and Redhat 9

imagem de 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

62 posts / 0 new
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.
imagem de Community Admin

> 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

imagem de Steve Lionel (Intel)

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

Steve
imagem de 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

imagem de Steve Lionel (Intel)

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

Steve
imagem de 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

imagem de 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

imagem de 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.



imagem de Community Admin

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

imagem de 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

imagem de Community Admin

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

imagem de 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...

imagem de 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

imagem de Community Admin

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......

imagem de 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.

imagem de 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

imagem de 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



imagem de 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

imagem de 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

imagem de 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.

imagem de 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.

imagem de 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





























imagem de 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

imagem de 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

imagem de Community Admin

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!

imagem de 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.

imagem de Brandon Hewitt (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 Hewitt Technical Consulting Engineer Tools Knowledge Base: "http://software.intel.com/en-us/articles/tools" Software Product Support info: "http://www.intel.com/software/support"
imagem de Brandon Hewitt (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

Brandon Hewitt Technical Consulting Engineer Tools Knowledge Base: "http://software.intel.com/en-us/articles/tools" Software Product Support info: "http://www.intel.com/software/support"
imagem de 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.

imagem de Brandon Hewitt (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

Brandon Hewitt Technical Consulting Engineer Tools Knowledge Base: "http://software.intel.com/en-us/articles/tools" Software Product Support info: "http://www.intel.com/software/support"
imagem de 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

imagem de Steve Lionel (Intel)

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

Steve

Steve
imagem de Brandon Hewitt (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

Brandon Hewitt Technical Consulting Engineer Tools Knowledge Base: "http://software.intel.com/en-us/articles/tools" Software Product Support info: "http://www.intel.com/software/support"
imagem de 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

imagem de 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-compa...

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

imagem de 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!

imagem de 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

imagem de mcelrath

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

You must specify -lIEPCF90 -lpthread *last*. You want those two to be linked after all your source files, object files, and other libraries. (remember that order matters when linking)

imagem de mcelrath

I really recommend my fix #2 (downgrade glibc). I compiled with that fix (grab the srpm, unpack, add patch and modify .spec file, make new srpm, then rpm --rebuild). I made an srpm but it was before I found the patch I posted. I think I did it wrong because in some circumstances I still get __ctype_b errors.

imagem de ivica_jan

I tried to rebuild glibc-2.3.2-4.80.6 but I have problem:
Here are THE STEPS I made:
download
glibc-2.3.2-4.80.6.src.rpm
after that
rpm -Uvh glibc-2.3.2-4.80.6.src.rpm
then in /usr/src/redhat/ i put patch you suggest
and changed .spec file in order to include that patch ..
rpmbuild -bs ../SPECS/glibc-8.0.spec
it created new .src and than rebuild
rpmbuild --rebuild glibc-2.3.2-4.80.6.src.rpm
and then there is ERROR (after some time of compilation, many were ok)

here is error:
gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.2 -B/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/csu/ -Wl,--version-script=/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -nostdlib -nostartfiles -e __libc_main -u __register_frame -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/math -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/elf -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/dlfcn -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/nss -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/nis -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/rt -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/resolv
-L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/crypt -L/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/linuxthreads -Wl,-rpath-link=/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/math:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/elf:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/dlfcn:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/nss:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/nis:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/rt:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/resolv:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/crypt:/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/linuxthreads -o /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc.so -T /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc.so.lds /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/csu/abi-note.o /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/elf/soinit.os /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc_pic.os /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/elf/sofini.os /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/elf/interp.os /usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/elf/ld.so -lgcc
/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc_pic.os(.debug_info+0x2935db): undefined reference to `I'
/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc_pic.os(.debug_info+0x2935e6): undefined reference to `I'
/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc_pic.os(.debug_info+0x293619): undefined reference to `I'
collect2: ld returned 1 exit status
make[1]: *** [/usr/src/redhat/BUILD/glibc-2.3.2-20030312/build-i386-linux/libc.so] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/glibc-2.3.2-20030312'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.40716 (%build)


RPM buil
d errors:
Bad exit status from /var/tmp/rpm-tmp.40716 (%build)


SO AT THE END I AM NOT ABLE TO install this glibc .. any hint?

imagem de mcelrath

Either do fix #1 or fix #2, you tried to do both. Just install the binary rpm's from rh8...

imagem de ivica_jan

oky I'll downgrade glibc to RH8.0 updated glibc-2.3.2-4.80.6
what packages I have to rpm -U --oldpackage?
1) glibc-2.3.2-4.80.6.i386.rpm
2) glibc-common-2.3.2-4.80.6.i386.rpm
3) glibc-devel-2-2.3.2-4.80.6.i386.rpm
4) glibc-utils-2.3.2-4.80.6.i386.rpm
5) nscd-2.3.2-4.80.6.i386.rpm


Is that all?
Thnks, Ivica

imagem de shawng

I tried method #2, downloaded: (put them all in the same directory)
1) glibc-2.3.2-4.80.6.i386.rpm
2) glibc-common-2.3.2-4.80.6.i386.rpm
3) glibc-devel-2-2.3.2-4.80.6.i386.rpm
4) glibc-utils-2.3.2-4.80.6.i386.rpm
5) glibc-debug-2.3.2-4.80.6.i386.rpm
6) nscd-2.3.2-4.80.6.i386.rpm

then issued the command:
rpm -U --oldpackage *.rpm

However after this completed, every program seg faulted there after and I had to re-upgrade those files defore anything would work again. Any Suggestions on my this happened or how to get around this problem? Thanks!

imagem de shawng

I first tried to "rpm -U --oldpackage" the files individulaly but I ran into dependency errors. Is there a certain order or a trick I am missing? Thanks again.

imagem de isn-removed200640

In consultation w/ Intel developer services I think I've solved the problem more or less completely.

First, get the files
libc-2.2.93.so
libpthread.so

from a RedHat 8.0 distribution (in my setup, these exist in both /lib and /lib/i686; I seem to need the files from the latter directory. I've then put them in /opt/intel/old_libs

Then, change the file /opt/intel/compiler70/ia32/bin/ifc.cfg to contain

-Xlinker -rpath -Xlinker /opt/intel/compiler70/ia32/lib -I/opt/intel/compiler70/ia32/include
-L/opt/intel/old_libs -lc-2.2.93

Now, everything should work as before. In addition to the old libc, this should pick out the old pthread library if you use -lpthread from the ifc command line.

imagem de Steve Lionel (Intel)

I wanted to let people here know that Intel engineering is currently evaluating RedHat 9 to see what it breaks and what can be done about it. When we know more, we'll post an update.

Steve

Steve
imagem de Community Admin

> I wanted to let people here know that Intel
> engineering is currently evaluating RedHat 9 to see
> what it breaks and what can be done about it. When
> we know more, we'll post an update.

I wanted to let Intel engineering know that we are looking
forward to have RH9 support.
Thank you for considering it.

imagem de dfumento

Would someone please e-mail me the proper RedHat 8 libc binary to fumento (at symbol) optonline.net?

There seems to be no way to extract the lib-xxx.so file from the RPM file without overwriting your Redhat 9 version.

Thank you

imagem de kyuho.lee

You can extract libc-2.2.93.so from glibc-2.2.93-5.i386.rpm;

> rpm2cpio glibc-2.2.93-5.i386.rpm | cpio -idv ./lib/libc-2.2.93.so

NOTE:
"./lib" can not be omitted!!
You can figure out the full path name:

> rpm2cpio glibc-2.2.93-5.i386.rpm | cpio -t | grep libc-2.2.93.so


- Kyuho

imagem de menscher

> I wanted to let people here know that Intel
> engineering is currently evaluating RedHat 9 to see
> what it breaks and what can be done about it. When
> we know more, we'll post an update.

A month has passed, and we're very eager to hear: any word on when this will be available?

Damian

imagem de joekrahn

Description and work-around for IFC 7.1 on RH9:

The missing ctype_b__ problem comes from the newer GLIBC.
This is a table of flags for C functions isupper() etc.
The newer GLIBC makes these functions locale-dependent, where data is obtained via a libc function call rather than a static data structure. The data actually still exists in glibc, but it is no longer exported. As usual, RedHat favors forward advancement over backward compatibility.

The work-around: All you need is your own copy of the ctype data. I'll attach the source for my ctype.c workaround, with instructions at the top of the file.

The real fix: Intel simply needs to compile it's libraries against the newer glibc, and it should work as is. Or, if that creates backward compatibility problems, just incorporate it's own static ctype table.

Hope this helps aeveryone. (Actually, I've been using it for a while, I just never noticed the Linux/IFC forum.)

Joe Krahn

Páginas

Faça login para deixar um comentário.