[MITgcm-devel] sun os
chris hill
cnh at mit.edu
Thu Sep 30 11:08:17 EDT 2004
Hi Martin,
It appears to create a rule that says if you need to create a .o file
then do nothing to the associated .F file. I think it may be needed for
cygwin or may have been needed at some point, thats when it was added,
but Ed will know better - he added it a few months ago.
If we are lucky it will turn out to be totally redundant, Ed will
delete it and everyone will be happy.
Chris
On Thu, 2004-09-30 at 11:01, Martin Losch wrote:
> "My sun" (actually a sun ray server) isn't any faster than fjord or
> slough (that's one of the reasons why I hate to test anything on a Sun,
> it ALWAYS feels like running on the chip in your toaster), but I
> commented out this line and now it compiles the fortran sources and
> creates a working executable. What does the
> %.o:%.F
> line do?
>
> Martin
>
> On Sep 30, 2004, at 4:39 PM, chris hill wrote:
>
> > Martin,
> >
> > Can you try commenting out the line
> >
> > %.o : %.F
> >
> > in Makefile generated by genmake2.
> >
> > I tried this on fjord and it seems to then compile object files.
> > Unfortunately fjord runs so slowly that I suspect it actually is your
> > toaster.
> >
> > Chris
> >
> > On Thu, 2004-09-30 at 02:12, Martin Losch wrote:
> >> Patrick et al.,
> >> sorry for the confusion. make depend does NOT fail in my case, I just
> >> get these "-traditional: not found warning" messages, couldn't find
> >> out
> >> where they come form. They have been around on Suns for a long time
> >> and
> >> they never mattered. They don't matter now, either. After make depend,
> >> make does not work, but gmake does. I find the same that Patrick
> >> finds.
> >>
> >> Martin
> >>
> >>
> >> On Sep 29, 2004, at 7:13 PM, Patrick Heimbach wrote:
> >>
> >>> Hi Martin,
> >>>
> >>> I just co-ed a fresh copy onto fjord.mit.edu
> >>>> uname -a
> >>> SunOS fjord 5.8 Generic_108528-09 sun4u sparc SUNW,Sun-Blade-1000
> >>>
> >>> I did global_ocean.90x40x15
> >>> genmake2 worked ok
> >>> 'make depend' worked ok
> >>> 'make' didn't work, but 'gmake' worked ok.
> >>>
> >>> I'm a bit confused since you said
> >>> 'make depend' already fails on you?
> >>> I checked my Makefile to make sure it uses
> >>> tools/xmakedepend as in your case.
> >>>
> >>> -Patrick
> >>>
> >>> PS:
> >>> fjord:/data37/heimbach/ecco/MITgcm/verification/
> >>> global_ocean.90x40x15/
> >>> build
> >>>
> >>>
> >>>
> >>> Quoting Martin Losch <mlosch at awi-bremerhaven.de>:
> >>>
> >>>> Hi again,
> >>>> here come the error messages (for exp4)
> >>>> rays1::bin> make depend
> >>>> [lots of linking als usual; then]
> >>>> ../../tools/xmakedepend -o .f -DWORDLENGTH=4 -DHAVE_SYSTEM
> >>>> -DHAVE_FDATE
> >>>> -DHAVE_ETIME -I. obcs_calc.F [... snip ....] write_state.F
> >>>> ./mdep27541a: -traditional: not found
> >>>> ./mdep27541a: -traditional: not found
> >>>> [... for each file ...]
> >>>> ./mdep27541a: -traditional: not found
> >>>> Appending dependencies to Makefile
> >>>> ../../tools/f90mkdepend >> Makefile
> >>>> echo: No match
> >>>> rm -f makedepend.out
> >>>> [so far so good the traditional messages probably come for the
> >>>> hardcode
> >>>> cpp compiler in xmakedepend]
> >>>> rays1::bin> make
> >>>> cc -dalign -O3 -xarch=v9 -c ptwrapper.c
> >>>> cc: Warning: option -3 passed to ld
> >>>> "ptwrapper.c", line 61: warning: empty translation unit
> >>>> cc -dalign -O3 -xarch=v9 -c tim.c
> >>>> cc: Warning: option -3 passed to ld
> >>>> cc -dalign -O3 -xarch=v9 -c timer_stats.c
> >>>> cc: Warning: option -3 passed to ld
> >>>> Creating mitgcmuv ...
> >>>> f77 -o mitgcmuv -stackvar -explicitpar -vpara -e -u -noautopar
> >>>> -xtypemap=real:64,double:64,integer:32 -fsimple=0 -dalign -O3
> >>>> -xarch=v9
> >>>> obcs_calc.o [...] timer_stats.o
> >>>> NOTICE: Invoking /opt/forte7/SUNWspro/bin/f90 -f77 -ftrap=%none -o
> >>>> mitgcmuv -stackvar -explicitpar -vpara -e -u -noautopar
> >>>> -xtypemap=real:64,double:64,integer:32 -fsimple=0 -dalign -O3
> >>>> -xarch=v9
> >>>> obcs_calc.o [etc same thing again]
> >>>> ld: fatal: file obcs_calc.o: open failed: No such file or directory
> >>>> ld: fatal: file chksum_tiled.o: open failed: No such file or
> >>>> directory
> >>>> ld: fatal: file debug_call.o: open failed: No such file or directory
> >>>> [...]
> >>>> ld: fatal: file write_state.o: open failed: No such file or
> >>>> directory
> >>>> ld: fatal: File processing errors. No output written to mitgcmuv
> >>>> *** Error code 1
> >>>> make: Fatal error: Command failed for target `mitgcmuv'
> >>>> rays1::bin>
> >>>>
> >>>> You can reproduce that on fjord.mit.edu if you have the patience.
> >>>> obviously, "make" doesn't compile the fortran sources before it
> >>>> tries
> >>>> to link everything.
> >>>>
> >>>> Martin
> >>>>
> >>>> On Sep 29, 2004, at 5:26 PM, chris hill wrote:
> >>>>
> >>>>> Hi Martin,
> >>>>>
> >>>>> Can you send the Sun make error message. It is a goal of ours to
> >>>>> make
> >>>>> sure things build and run on anything *nix, even your toaster. Our
> >>>>> official policy is
> >>>>>
> >>>>> (1) - we always make things work with gmake
> >>>>> (2) - with other makes we abuse you a bit first and then try and
> >>>>> fix
> >>>>> the problem if we can
> >>>>>
> >>>>> but for (2) we do need to get error messages to see what the
> >>>>> problem
> >>>>> is.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Chris
> >>>>> On Wed, 2004-09-29 at 09:12, Martin Losch wrote:
> >>>>>> Hi again,
> >>>>>> personally I am perfectly fine with gmake; as someone said before,
> >>>>>> it's
> >>>>>> what everybody has (or can have). It's just another thing to
> >>>>>> remember
> >>>>>> when you do something on a Sun (not that I seriously intend to do
> >>>>>> so).
> >>>>>> It's similar to the NetCDF discussion: if something doesn't work
> >>>>>> on
> >>>>>> a
> >>>>>> particular machine, that's fine, as long as there is an
> >>>>>> explanation
> >>>>>> for
> >>>>>> it and an obvious way to fix it. It's probably enough to emphasize
> >>>>>> the
> >>>>>> make/gmake issue in the documentation, for example on
> >>>>>> http://mitgcm.org/pelican/online_documents/node90.html
> >>>>>>
> >>>>>> Martin
> >>>>>>
> >>>>>> On Sep 29, 2004, at 2:43 PM, Ed Hill wrote:
> >>>>>>
> >>>>>>> On Wed, 2004-09-29 at 02:51, Martin Losch wrote:
> >>>>>>>> My favorite operating system! Yesterday I tried to compile one
> >>>>>>>> experiment (basically exp4) on one of our SunOS computers, but
> >>>>>>>> it
> >>>>>>>> failed at the make-step (both with the default optfile and with
> >>>>>>>> sunos_sun4u_f77 where MAKE=gmake is specified):
> >>>>>>>>>> make
> >>>>>>>> compiled the c-code and then tried to link, of course it failed,
> >>>>>>>> because no fortran source had been compiled.
> >>>>>>>> I then found out that gmake works. I remember that there was a
> >>>>>>>> discussion about that, but what's the status? Is the inapt
> >>>>>>>> sun-user
> >>>>>>>> (that's me) supposed to know that gmake has to be used instead
> >>>>>>>> of
> >>>>>>>> make?
> >>>>>>>> On
> >>>>>>>>> http://mitgcm.org/pelican/online_documents/node90.html
> >>>>>>>> "make" is still the command to use.
> >>>>>>>> (It was quite embarrassing that after I have been claiming that
> >>>>>>>> the
> >>>>>>>> MITgcm "compiles and runs everywhere without any problems", it
> >>>>>>>> didn't
> >>>>>>>> compile and I didn't know why (took me some time to remember
> >>>>>>>> gmake)
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi Martin,
> >>>>>>>
> >>>>>>> What can we say? For starters, theres no comprehensive standard
> >>>>>>> for
> >>>>>>> the
> >>>>>>> 'make' syntax so no one can claim that their 'make'
> >>>>>>> implementation
> >>>>>>> is
> >>>>>>> 100% standards compliant. And the various ("old Unix vendor")
> >>>>>>> 'make'
> >>>>>>> implementations are _infamous_ for having been somewhat
> >>>>>>> incompatible
> >>>>>>> with each other. Its the old "fracturing of Unix" story...
> >>>>>>>
> >>>>>>> So the MITgcm Makefile has gained a lot of features over the past
> >>>>>>> year
> >>>>>>> (including the ability to build without any tweaking on Mac OS X
> >>>>>>> and
> >>>>>>> Windows with Cygwin). This increased complexity means that some
> >>>>>>> (not
> >>>>>>> all!) older 'make' implementations can't handle it. And I'm
> >>>>>>> sorry.
> >>>>>>> We've chose Gnu Make as our de-facto standard because its
> >>>>>>> available
> >>>>>>> basically everywhere and it supports the syntax we need. And if
> >>>>>>> you're
> >>>>>>> unlucky enough to be on a machine that doesn't have Gnu Make or a
> >>>>>>> sufficiently compatible make already installed, a local build is
> >>>>>>> this
> >>>>>>> easy:
> >>>>>>>
> >>>>>>> $ wget ftp://aeneas.mit.edu/pub/gnu/make/make-3.80.tar.gz
> >>>>>>> $ tar -xzf make-3.80.tar.gz
> >>>>>>> $ cd make-3.80
> >>>>>>> $ ./configure
> >>>>>>> $ make
> >>>>>>>
> >>>>>>> Also, theres a comment about 'make' versus 'gmake' at
> >>>>>>>
> >>>>>>> http://mitgcm.org/pelican/online_documents/node92.html
> >>>>>>>
> >>>>>>> and we'll add more information to the docs during the upcoming
> >>>>>>> DocFest
> >>>>>>> (in mid-October).
> >>>>>>>
> >>>>>>> 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-devel mailing list
> >>>>>>> MITgcm-devel at mitgcm.org
> >>>>>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MITgcm-devel mailing list
> >>>>>> MITgcm-devel at mitgcm.org
> >>>>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>>
> >>>>> _______________________________________________
> >>>>> MITgcm-devel mailing list
> >>>>> MITgcm-devel at mitgcm.org
> >>>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>
> >>>> _______________________________________________
> >>>> MITgcm-devel mailing list
> >>>> MITgcm-devel at mitgcm.org
> >>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>
> >>>
> >>>
> >>> --------------------------------------------------------
> >>> Patrick Heimbach Massachusetts Institute of Technology
> >>> FON: +1/617/253-5259 EAPS, Room 54-1518
> >>> FAX: +1/617/253-4464 77 Massachusetts Avenue
> >>> mailto:heimbach at mit.edu Cambridge MA 02139
> >>> http://www.mit.edu/~heimbach/ USA
> >>>
> >>
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list