Prev: Reopening standard input/output (Was: RECL)
Next: Passing Array-valued functions TO procedures
From: elijah on 11 Apr 2008 11:41
hi group,

I am a PhD student, and in my project I have to modify some
subroutines of codes that were written in fortran. I have a basic
knowledge of fortran as I do not have a background of compouter
science.

I have two different codes written in fortran. Both have scripts for
compiling and linking provided by the suppliers.

For Code-1: I modify the subroutine compile and link by using the
supplied script. In the script I see the options "-static" -lpthread -
ldl etc. an executable is generated. it works fine. system being
Mandrake LINUX 2.4.22, compiler: intel_fc_81. Code-1 does not require
mkl.

on the same computer

For Code-2: the compilation works fine, but when I ask for linking
with the option "-static" -lpthread -ldl etc. I get the errors that
lpthread, ldl are missing (I can see them, they exist and work fine
with Code-1). when I take out the option "-static" the executable is
generated with an error:

liblcpack.a(IIRVmgr_init.o)(.text+0x717): In function
`IIRVmgr_initOutOfCore':
: the use of `tmpnam' is dangerous, better use `mkstemp'

the the executable takes 4 hrs 49 mins to solve the problem which I
can solve in 38 mins.

does anyone have an idea where the problem might be. and what is the
workaround for this.

thanks in advance
From: FX on 11 Apr 2008 11:43
> when I take out the option "-static" the executable is generated with
> an error:
>
> liblcpack.a(IIRVmgr_init.o)(.text+0x717): In function
> `IIRVmgr_initOutOfCore':
> : the use of `tmpnam' is dangerous, better use `mkstemp'

This is not an error, but a warning. Moreover, it is certainly unrelated
to your slowdown problem.

--
FX
From: Steven Correll on 12 Apr 2008 01:19
On Apr 11, 8:41 am, elijah <mily...(a)gmail.com> wrote:
> For Code-1: I modify the subroutine compile and link by using the
> supplied script. In the script I see the options "-static" -lpthread -
> ldl etc. an executable is generated. it works fine. system being
> Mandrake LINUX 2.4.22, compiler: intel_fc_81. Code-1 does not require
> mkl.
>
> on the same computer
>
> For Code-2: the compilation works fine, but when I ask for linking
> with the option "-static" -lpthread -ldl etc. I get the errors that
> lpthread, ldl are missing (I can see them, they exist and work fine
> with Code-1).

For best results, you should generally copy and paste the evidence (in
this case, the linking command and the error messages) into your
message
to comp.lang.fortran, rather than composing a prose narrative of what
you did and what happened as a result. The reason is that the problem
is often in some detail that one is apt to omit from the prose.

Apart from that, a couple of general suggestions: The Linux
linker option "--trace" is often helpful with library-finding issues
(if you are using "ifort" to link, you'll have to pass it through
ifort to the linker by saying "-Wl,--trace".) The "-v" option will
make "ifort" show you the "ld" command which it is generating on
your behalf. Any chance it's a 64-vs-32 bit issue? I've seen Linux
installations where the 64-bit static libraries were correct but
the 32-bit libraries were not, or vice versa; that can go unnoticed
for some time if people rarely use static linking. Unfortunately
the "file" command is helpful in this regard with .so dynamic libs
but not with .a static libs: you have to extract a .o file from the
..a file with "ar" and then run "file" on the .o file to check
whether it's the right architecture and bit-ness.
From: Anonymous #1 on 12 Apr 2008 08:57

"elijah" <milyas7(a)gmail.com> wrote in message
news:e50071c7-5cec-44a0-ac49-855f6ada9bf4(a)c65g2000hsa.googlegroups.com...
> hi group,
>
> For Code-1: I modify the subroutine compile and link by using the
> supplied script. In the script I see the options "-static" -lpthread -
> ldl etc. an executable is generated. it works fine. system being
> Mandrake LINUX 2.4.22, compiler: intel_fc_81. Code-1 does not require
> mkl.
>
> on the same computer
>
> For Code-2: the compilation works fine, but when I ask for linking
> with the option "-static" -lpthread -ldl etc. I get the errors that
> lpthread, ldl are missing (I can see them, they exist and work fine
> with Code-1). when I take out the option "-static" the executable is
> generated with an error:
>
> liblcpack.a(IIRVmgr_init.o)(.text+0x717): In function
> `IIRVmgr_initOutOfCore':
> : the use of `tmpnam' is dangerous, better use `mkstemp'
>

You did not provide the script, there is no way to see the problem.

According to what you posted, the script for Code-1 has no problem to link
against -static -lpthread -ldl ..., the script for Code 1 may export
environmental variable to search libraries; while the script for Code 2 may
fail to export such environmental variable. As stated previouly, you did not
provide the script, no way to tell the exact cause. Just a guess.

Kind regards



From: elijah on 14 Apr 2008 05:14
hi guys,

here is the script for Code-2 without "-static"

/usr/local/intel_fc_81/bin/ifort -openmp -fpp2 -o myexec
dynm.o dyn21.o dyn21b.o adummy_graph.o orderByMetis.o lcfunc.o
adummy_msc.o mscapi.o libdyna.a libbcsext4.a liblsda.a liblssecurity.a
libdmf.a libmetis.a liblcpack.a libspooles.a libcparse.a liblsm.a
liblscrypt.a ia32_81_libansys.a -lsvml -lpthread -ldl /usr/local/
mkl_8.0/lib/32/libmkl_lapack.a /usr/local/mkl_8.0/lib/32/libmkl_ia32.a

and the output is

liblcpack.a(IIRVmgr_init.o): In function `IIRVmgr_initOutOfCore':
init.c:(.text+0x717): warning: the use of `tmpnam' is dangerous,
better use `mkstemp'

with "-static"

/usr/local/intel_fc_81/bin/ifort -openmp -fpp2 -o myexec
dynm.o dyn21.o dyn21b.o adummy_graph.o orderByMetis.o lcfunc.o
adummy_msc.o mscapi.o libdyna.a libbcsext4.a liblsda.a liblssecurity.a
libdmf.a libmetis.a liblcpack.a libspooles.a libcparse.a liblsm.a
liblscrypt.a ia32_81_libansys.a -static -lsvml -lpthread -ldl /usr/
local/mkl_8.0/lib/32/libmkl_lapack.a /usr/local/mkl_8.0/lib/32/
libmkl_ia32.a

output is

ld: cannot find -lpthread

operating system is mandrake linux 32bit, on intel xeon 32bit double
processor machine

kind regards
MI
 |  Next  |  Last
Pages: 1 2
Prev: Reopening standard input/output (Was: RECL)
Next: Passing Array-valued functions TO procedures