[MITgcm-devel] sun os
Martin Losch
mlosch at awi-bremerhaven.de
Thu Sep 30 11:01:55 EDT 2004
"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
More information about the MITgcm-devel
mailing list