topic Re: ifort+macosx+mpich2+libtools => _$non_lazy_ptr in Intel® Fortran Compiler

ifort+macosx+mpich2+libtools => _$non_lazy_ptr

srinath — Mon, 07 Jul 2008 19:52:42 GMT

I will admit that it is quite difficult to explain what I'm experiencing, but subsequent questions will help.
OS: Mac OS X 10.5.4
compiler: Ifort 10.1.15
MPICH: mpich2-1.0.7
libtool: Apple Computer, Inc. version cctools-667.3

Using the autotools to build the project I can successfully build only with building shared libraries. If I try building with static libraries, variables that are common to modules get a "_$non_lazy_ptr" appended to their reference from the mpich wrappers for ifort before being sent to ld. This does not happen with a gfortran build of mpich2. The similar happenings occur with ifort/gfortran builds of OpenMPI.

Searching on the interweb shows that the intel compiler on macs is the only one doing the appending of wierd symbols. Note: "nm-ing" the libraries reveal that there is no symbol with the "$" suffix.

Re: ifort+macosx+mpich2+libtools => _$non_lazy_ptr

Ron_Green — Mon, 07 Jul 2008 20:08:01 GMT

I'm not sure if you are using Autoconf or the pre-packaged configure script with Mpich and OpenMPI.

We have an OpenMPI doc at http://support.intel.com/support/performancetools/sb/CS-026988.htm

I haven't tried mpich2 on a Mac lately. I've been pretty happy with OpenMPI. I'll give it a try and let you know what I find. Is there a reason you are forcing the static build and not creating the dynamic libs?

What does your configure line look like for mpich - that will save me some time.

thanks

ron

Re: ifort+macosx+mpich2+libtools => _$non_lazy_ptr

srinath — Mon, 07 Jul 2008 20:43:22 GMT

I have been forcing static libraries builds because visual debuggers such as totalview seem to like it better than trying to traverse dynamically loaded libraries.

The following is obliviously project specific, but may guide you:
/bin/sh ../../libtool --mode=link /usr/local/openmpi/1.2.6rc2/ifort32/bin/mpif90 -autodouble -I ../../gyro/src/src -I ../../gyro/ORB -I ../../gyro/BLEND -I ../../gyro/math -I ../../gyro/TRANSPOSE -I ../../gyro/SSUB -I ../../gyro/GEO -I ../../gyro/UMFPACK -L/usr/local/lib -lrfftw -lfftw -framework Accelerate -framework Accelerate -g -o BigScience BigScience_globals.o get_inputpath.o BigScience.o ../../gyro/src/src/libgyro.la ../../gyro/src/ORB/libORB.la ../../gyro/src/BLEND/libBLEND.la ../../gyro/src/math/libgyromath.la ../../gyro/src/TRANSPOSE/libTRANSP.la ../../gyro/src/SSUB/libSSUB.la ../../gyro/src/GEO/libGEO.la ../../gyro/src/UMFPACK/libUMFPACK.la
mkdir .libs
/usr/local/openmpi/1.2.6rc2/ifort32/bin/mpif90 -autodouble -I ../../gyro/src/src -I ../../gyro/ORB -I ../../gyro/BLEND -I ../../gyro/math -I ../../gyro/TRANSPOSE -I ../../gyro/SSUB -I ../../gyro/GEO -I ../../gyro/UMFPACK -framework Accelerate -framework Accelerate -g -o BigScience BigScience_globals.o get_inputpath.o BigScience.o -L/usr/local/lib /usr/local/lib/librfftw.dylib /usr/local/lib/libfftw.dylib -lm ../../gyro/src/src/.libs/libgyro.a ../../gyro/src/ORB/.libs/libORB.a ../../gyro/src/BLEND/.libs/libBLEND.a ../../gyro/src/math/.libs/libgyromath.a ../../gyro/src/TRANSPOSE/.libs/libTRANSP.a ../../gyro/src/SSUB/.libs/libSSUB.a ../../gyro/src/GEO/.libs/libGEO.a ../../gyro/src/UMFPACK/.libs/libUMFPACK.a

Also:
srinath@proton:~$ automake --version
automake (GNU automake) 1.10
Written by Tom Tromey
and Alexandre Duret-Lutz .

Copyright 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

srinath@proton:~$ autoconf --version
autoconf (GNU Autoconf) 2.61
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <>.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

These have been upgraded from the cctools 667.3. Note: the newest autoconf does not play well with any of the newer automakes...GNU community is really dropping the ball on this....can anyone say SCONS?

Re: ifort+macosx+mpich2+libtools => _$non_lazy_ptr

Ron_Green — Tue, 08 Jul 2008 14:40:17 GMT

my search of the internal database only found some old references, old being v9.0 timeframe, for the C++ compiler on Linux - this seemed totally unrelated to what you are seeing. Further research on the web shows that the non_lazy_ptr is definitely a C++ symbol. Another interesting web find was that this only seems to affect Leopard, not Tiger nor Linux. Unfortunately, of the 2 pages of hits I searched from a search on 'non_lazy_ptr' there seems to be no clear solution, just a lot of vague handwaving and blaming Leopard. Also, this does not appear to be an Intel Fortran issue, as most of the hits had nothing to do with Fortran, except a curiously similar issue with LAM-MPI's interfaces to Fortran.

Here is what I found to be the most definitive and interesting one:

http://forums.macosxhints.com/showthread.php?p=480533

Note that this is strictly C++ compiled on Leopard with the recent C++ compiler. This thread implies that the newer Mac C++ compiler is not allowing static const double, which the older Mac C++ compilers allowed. Perhaps both LAM-MPI and MPICH2 are using this construct? Or perhaps your application is using this construct? It would be interesting for you to try installing an older Xcode 2.4 w/ compilers and tools and see if the problem persists.

And our Fortran compiler does not use 'non_lazy_ptr' in any of it's symbol decoration, as your 'nm' has shown.

I'll dig into the MPICH code a bit to see if I can find anything, but at this point I'm stumped.

Other interesting web references:

LAM-MPI plus Intel compilers , but Leopard and Xcode 3.0:
http://www.lam-mpi.org/MailArchives/lam/2007/10/13457.php

A non-Intel, non-fortran case:
http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.mac.programmer.help/2008-03/msg00002.html

Postgres 8.2 issue: non-Fortran, non-Intel:
http://lists.macosforge.org/pipermail/macports-users/2007-October/006550.html

and about 2 more pages of search hits with no clear common thread other than Leopard and Xcode 3.0.

ron

Re: ifort+macosx+mpich2+libtools => _$non_lazy_ptr

srinath — Tue, 08 Jul 2008 19:13:23 GMT

Thank you for the results of your investigation. I see that the compiler (Intel ifort) does not supply the $non_lazy_ptr, but it seems to be inserted when the mpif90 script hands things over to ld. I'm starting to believe that this may be a Leopard ld issue, because this also happens with my ifort-OpenMPI implemented MPICH.

I'll continue to hunt. Thank you again. I am a little werry of depricating Xcode (and cctools) because of modern application builds.

Re: ifort+macosx+mpich2+libtools => _$non_lazy_ptr

srinath — Tue, 08 Jul 2008 21:33:46 GMT

It looks like the "as" assembler is the culprit. It seems to be adding this $non_lazy_ptr suffix to symbols before handing things over to the linker. I'm not sure why it adds this suffix for the symbols created by the intel compiler, and not gfortran.

Re: ifort+macosx+mpich2+libtools => _$non_lazy_ptr

srinath — Wed, 09 Jul 2008 22:32:18 GMT

We have determined what the issue is:
For ifort: One must initialize at least 1 declared common variable before using any of the variables in the module within a main program. Gfortran automatically initializes variables. This is the $non_lazy_ptr common variable conflict that the Mac OS X assembler documentation refers to (read the book...;). It seems that if 1 used common variable is initialized, then the ifort compiler initializes the rest to default values. We have some sample code to demonstrate this (requires use of libraries):

module lazyptr_private
implicit none
INTEGER, PARAMETER :: i4=SELECTED_INT_KIND(9)

integer(i4) :: test3
real :: test4
real*8 :: test5
character*8 :: test6
integer :: test10
integer :: test1
integer :: test2=0

end module lazyptr_private
----------------------------

SUBROUTINE test1sub
USE lazyptr_private

write(*,*) "this is test1 = ",test1
test1=4
write(*,*) "this is test1 = ",test1
test2=2
write(*,*) "this is test2 = ",test2
test3=3
write(*,*) "this is test3 = ",test3
test4=4
write(*,*) "this is test4 = ",test4
write(*,*) "this is test5 = ",test5
test6='six'
write(*,*) "this is test6 = ",test6
test10=10
write(*,*) "this is test10 = ",test10

END SUBROUTINE
----------------------------
PROGRAM lazyptr

IMPLICIT NONE

CALL test1sub
END PROGRAM
---------the Makefile vvv---------------
FC=ifort
#FC=gfortran

all: lazyptr_test

liblazyptr.a: lazyptr_sub.o lazyptr_private.o
libtool -o liblazyptr.a lazyptr_private.o lazyptr_sub.o

lazyptr_test: lazyptr_test.o liblazyptr.a
$(FC) -o $(@) $(^)

.f90.o:
$(FC) -c $(<)

lazyptr_private.o:
lazyptr_sub.o: lazyptr_private.o
lazyptr_test.o: liblazyptr.a

clean:
rm lazy*.o lazyptr_test lazy*.mod

.SUFFIXES: .f90
---------------------------------
You can play with different combinations of initializations, which variables are used in the subroutine, and compiler. Mystery solved! Ifort will default initialize all uninitialized variables declared in a module for "common/global" use, only after you explicitly initialize any one or more variables, and make sure that variable is used in the program.