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