On 02/02/2008, Adam C Powell IV wrote:
> On Thu, 2008-01-31 at 07:40 -0500, Adam C Powell IV wrote:
> > On Thu, 2008-01-31 at 11:36 +0530, Kumar Appaiah wrote:
> > > Further diagnosis showed that these are the error causing lines, along
> > > with the fixes:
> > >
> > > diff -u mpich-1.2.7/src/fortran/configure
> > > mpich-1.2.7/src/fortran/configure
> > > --- mpich-1.2.7/src/fortran/configure
> > > +++ mpich-1.2.7/src/fortran/configure
> > > @@ -15820,11 +15820,11 @@
> > > # turn off f90
> > > F90=""
> > > else
> > > - F90_MODINCFLAG="`$MAKE -f ../../f90modules/Makefile f90modflag`"
> > > - F90MODINCSPEC="`$MAKE -f ../../f90modules/Makefile f90modspec`"
> > > + F90_MODINCFLAG="`$MAKE -s -f ../../f90modules/Makefile
> > > f90modflag`"
> > > + F90MODINCSPEC="`$MAKE -s -f ../../f90modules/Makefile f90modspec`"
> > > if test -z "$USER_SET_F90INC" -a -z "$F90INC" ; then
> > > # This should use a test or try to get it from the f90module.
> > > - F90INC=`$MAKE -f ../../f90modules/Makefile f90incflag`
> > > + F90INC=`$MAKE -s -f ../../f90modules/Makefile f90incflag`
> > > fi
> > > fi
> > > fi
> > >
> > > For some reason, make was printing "make[1]: entering directory..."
> > > (and confusing the build). And this resulted in a bad config.status,
> > > with sed errors (and commands like sed s,make[1] ...), which produced
> > > an empty mpe_fortdefs.h, which didn't result in defines for the
> > > relevant MPI_* stuff.
>
> I'm not getting something here. In my build, and I see in yours as
> well, there's this:
>
> make --no-print-directory mpi-addons
> Making a shared library of libmpich.a
> farg.o: In function `mpir_iargc_':
> farg.f:(.text+0x9): undefined reference to `_gfortran_iargc'
> farg.o: In function `mpir_getarg_':
> farg.f:(.text+0x39): undefined reference to `_gfortran_getarg_i4'
> collect2: ld returned 1 exit status
> Successfully linked libmpich.a
> Making a shared library of libpmpich.a
> farg.o: In function `mpir_iargc_':
> farg.f:(.text+0x9): undefined reference to `_gfortran_iargc'
> farg.o: In function `mpir_getarg_':
> farg.f:(.text+0x39): undefined reference to `_gfortran_getarg_i4'
> collect2: ld returned 1 exit status
> Successfully linked libpmpich.a
> Making a shared library of libfmpich.a
> farg.o: In function `mpir_iargc_':
> farg.f:(.text+0x9): undefined reference to `_gfortran_iargc'
> farg.o: In function `mpir_getarg_':
> farg.f:(.text+0x39): undefined reference to `_gfortran_getarg_i4'
> collect2: ld returned 1 exit status
> Successfully linked libfmpich.a
> Making a shared library of libpmpich++.a
> Successfully linked libpmpich++.a
> Testing that MPI applications can be linked with shared libs...
This is due to the following patch I introduced:
@@ -170,7 +170,10 @@
libbase=`basename $libname .a`
# The -h name sets the name of the object; this is necessary to
# ensure that the dynamic linker can find the proper shared library.
- if $CLINKER -shared -Wl,-h,$libbase.$slsuffix -o
../shared/$libbase.$slsuffix *.o $OtherLibs ; then
+ export F77_GETARGDECL="intrinsic GETARG"
+ if $CLINKER -shared -Wl,-h,$libbase.$slsuffix -o
../shared/$libbase.$slsuffix *.o $OtherLibs ; then
+ echo Successfully linked $libname
+ elif gfortran -shared -Wl,-h,$libbase.$slsuffix -o
../shared/$libbase.$slsuffix *.o $OtherLibs ; then
echo Successfully linked $libname
else
echo "Linking $libname shared lib failed "
Note that $CLINKER will fail to resolve the getarg calls. However, the
elif case retries with gfortran, and thus, ends up linking fine. The
ideal solution would be for you to use $CLINKER for those stuff which
don't need GETARG, and gfortran for linking the stuff which uses
GETARG.
> Funny thing is, the libraries are there, and mpicc seems to be able to
> use them. So it seems to work, but I'm not sure I understand how or
> why... Any ideas?
So, I'd suggest you list out the libraries which need getarg, and link
them using gfortran, and others using $CLINKER. Sounds OK?
> I've neatened up the patches, and am putting everything at
> http://lyre.mit.edu/~powell/mpich/ with a bunch of new mpif90 support
> stuff. If you're sure it's right, I'll upload it. But it will have to
> get through the new queue because of the ldbl->gf name change.
I guess things should be fine, though you might want others with
rdepends to check. To allay fears of breakage, experimental might be
OK?
> Thanks again, this is a real milestone for the mpich package!
I am glad to have been of help!
> [BTW, are you on debian-beowulf and/or debian-science? If so, I won't
> CC you in my announcement to those lists of the mpich transition.]
No, I am not (yet). Please do CC me, though I'll be a mere observer.
Many thanks.
Kumar
--
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
