solution found; was: Re: [MITgcm-support] no -mpi option forgenmake2

Wed Aug 11 12:21:52 EDT 2004

Chris, Ed:

Just to straighten the record: the problems I reported with CVS were not
confined to Mac OSX. I had similar issues on a Linux box. And not just
with cvs update. Using cvs to checkout a fresh copy resulted in an
incomplete download. This has happened a number of times now so as
per your advice I henceforth download the .tar.gz directly.

Samar

On Wed, 11 Aug 2004, m. r. schaferkotter wrote:

> chris and ed:
>
> first the cvs update is on a lintel system (not Mac-osx). i/m updating
> my copy at work (lintel) and home is (OSX).
>
> did exactly as ed suggested:
>
>   'cvs -q up -d -P' in the $MITGCM_ROOT
>
> but notice:
>
> [me at mach MITgcm]$ cvs -q up -d -P
> ? eesupp/src/exch_uv_agrid_xy.rl.F
> ? eesupp/src/exch_uv_agrid_xy.rs.F
> ? eesupp/src/exch_uv_agrid_xyz.rl.F
> ? eesupp/src/exch_uv_agrid_xyz.rs.F
> ? pkg/mom_common
> ? tools/cyrus-imapd-makedepend
> ? tools/genmake2.0
> ? tools/build_options/linux_ia32_pgf77+mpi.0
> ? tools/build_options/linux_ia32_pgf77+mpi.1
> ? tools/build_options/linux_ia32_pgf77.0
> ? verification/lock
> ? verification/lock_MPI
> ? verification/advect_xz/run
> ? verification/exp4/run
> ? verification/plume_on_slope/eedata
> ? verification/plume_on_slope/run
>
> the exch_uv et.al. are precisely the ones that come up later in the
> process.
>
> make CLEAN
>
> (note make CLEAN has a different result than make clean; i had been
> doing make clean
>
> make makefile
>
> (i had not been doing that; following a note from eh3 20040407 in
> MITgcm-support group)
> make depend
>
> make
>
> and we end up in the same place with the multiple inclusion
> problems(one of five or so):
>
> exch_uv_agrid_xy.rl.o(.text+0x10): In function `exch_uv_agrid_xy_rl_':
> : multiple definition of `exch_uv_agrid_xy_rl_'
>
>
> obviously, from the anecdotal evidence there is a symptom here.
>
> i/m not sure it/s worth the effort to go further on the non-fresh copy.
>
> BTW: where does everyone put their own experiments?
>
> michael
>
> ---------
>
>
> On Wednesday, August 11, 2004, at 09:54 AM, Chris Hill wrote:
>
> > Hi Michael,
> >
> >  The exch_ files you noticed are auto generated from templates. These
> > templates are downloaded from CVS and then the exch_ files get created
> > the
> > first time you run genmake2. That is part of the reson there are far
> > fewer
> > in a fresh download.
> >
> >  You are the second person recently who has had some strange issues
> > with
> > "cvs update" (both on Mac/OS-X) so keep us posted if you notice
> > anything
> > else odd. We will do some tests here to see if we can find a problem
> > at our
> > end.
> >
> > Chris
> >
> >
> >> -----Original Message-----
> >> From: mitgcm-support-bounces at mitgcm.org
> >> [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of Ed Hill
> >> Sent: Wednesday, August 11, 2004 10:43 AM
> >> To: MITgcm-support
> >> Subject: Re: solution found; was: Re: [MITgcm-support] no
> >> -mpi option forgenmake2
> >>
> >> On Wed, 2004-08-11 at 09:51, m. r. schaferkotter wrote:
> >>> p:
> >>>
> >>> 1) success.
> >>>
> >>> adding
> >>>
> >>> CPP='/lib/cpp  -traditional -P'
> >>>
> >>> built the fresh copy successfully (good),  but not the version that
> >>> was updated with  'cvs -q up -d -P'.
> >>
> >> Hi Michael,
> >>
> >> Thats good news!  And now that you have the MPI builds
> >> working, I hope it runs well for you!
> >>
> >>
> >>> 2) an aside
> >>>
> >>> the updated code build stops with numerous complaints such as:
> >>>
> >>> exch_uv_agrid_xy.rl.o(.text+0x10): In function
> >> `exch_uv_agrid_xy_rl_':
> >>> : multiple definition of `exch_uv_agrid_xy_rl_'
> >>> exch_uv_agrid_xy_rl.o(.text+0x10): first defined here.
> >>>
> >>> i tracked this down to the eesupp/src directory. in the fresh copy
> >>> there are far fewer files.
> >>>
> >>> in the updated version:
> >>> [me at mach src]$ ls exch_uv_agrid_xy[_.]rs.F exch_uv_agrid_xy_rs.F
> >>> exch_uv_agrid_xy.rs.F
> >>>
> >>> it seems that the updated version has a number of file
> >> pairs that have
> >>> different names, but contain the same subroutine.
> >>>
> >>> [me at machsrc]$ grep "   subroutine" exch_uv_agrid_xy[_.]rl.F
> >>> exch_uv_agrid_xy_rl.F:      subroutine exch_uv_agrid_xy_RL(
> >>> component1,component2, myThid )
> >>> exch_uv_agrid_xy.rl.F:      subroutine exch_uv_agrid_xy_RL(
> >>> component1,component2, myThid )
> >>>
> >>>
> >>> seems to indicate something is askew with the cvs process
> >> (and/or my
> >>> use of cvs).
> >>> grabbing fresh cvs versions contributes to 'versionitis'.
> >>>
> >>> how does one salvage the updated version?
> >>
> >>
> >> The CVS update works for me on every platform that I've tried
> >> it on.  I do cvs updates fairly often using 'cvs -q up -d -P'
> >> in the $MITGCM_ROOT directory followed by a complete re-build
> >> ("make CLEAN && make makefile && make depend && make") in the
> >> necessary build directory (or directories).
> >>
> >> Did you skip the "make CLEAN" and/or the "make makefile"
> >> steps?  Or did you try to "cvs up" only a few of the
> >> files/directories--not all of them?  If so, thats why its
> >> failing.  After a complete cvs update of all the files and
> >> directories, you will then need to re-run the entire build
> >> process to add any new files, dependencies, etc. to your Makefile(s).
> >>
> >> And if you've done the "cvs up" and the re-build correctly,
> >> then [by definition! ;-)] you will have accomplished the same
> >> thing as grabbing a fresh copy and building it.  Its usually
> >> easier to start from a fresh copy and thats why its recommended.
> >>
> >> Ed
> >>
> >> --
> >> Edward H. Hill III, PhD
> >> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
> >>              Cambridge, MA 02139-4307
> >> emails:  eh3 at mit.edu                ed at eh3.com
> >> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> >> phone:   617-253-0098
> >> fax:     617-253-4464
> >>
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> >>
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> >
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>