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

Wed Aug 11 12:14:28 EDT 2004

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
>