[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
19990701: McIDAS-X 7.60 on Dec Alpha using gcc/f2c
- Subject: 19990701: McIDAS-X 7.60 on Dec Alpha using gcc/f2c
- Date: Thu, 01 Jul 1999 09:27:46 -0600
>From: "Alliss, Randall J." <address@hidden>
>Organization: TASC
>Keywords: 199907011100.FAA08534 McIDAS-X DEC
Randy,
>As Denise mentioned we have built and compiled McIDAS7.6 on our Dec ALPHA
>using gcc2.9.1, f2c and the OS4.0f. I did have to make 1 change in
>mcimagem.c. I had to comment a call to "setpgrp" out. Actually the code
>tells you this call is not really needed.
I have been making a similar change to mcimagem.c since version 7.1.
My code modification looks like:
if (detach)
{
if (setsid() == -1)
{
return -1;
}
#if 0 /* <<<<< UPC mod 981201 >>>>> */
if (setpgrp() == -1)
{
#ifndef __hpux
return -1;
#endif /* __hpux */
}
#endif /* __OPENNT || __osf__ */
>I can launch McIDAS and it fires up, however, any commands which try to
>access data returns an error. ie. IMGLIST, DSINFO etc. This is the case
>whether the data is local (ie. /mcidas/data) or from the ingestor. The error
>i get when issuing DSINFO I EAST ( which is GOES east ingest data)
>is the following:
>
>SERVER RETURNED ERROR NUMBER 1130458734
>ONTACT SERVER (CONNECT() FAILED)
What does the trace file look like:
DSINFO I EAST TRACE=1
To be honest, I don't know if DSINFO suppots TRACE=; if not, try getting
the trace output from IMGLIST: 'IMGLIST EAST/whatever TRACE=1. The trace
file will be found in the mcidas/data directory of the user running
the ADDE server (either you or mcadde).
I built 7.6 (and 7.[12345] successfully on our DEC Alpha running Digital Unix.
Our current OS version is:
Digital UNIX V4.0D (Rev. 878); Sun Feb 1 15:52:19 MST 1998
I have never seen this error. Here are the results of a couple of
non-session McIDAS-X invocations:
dataloc.k
Group Name Server IP Address
-------------------- ----------------------------------------
MYDATA <LOCAL-DATA>
RTGRIDS ADDE.UNIDATA.UCAR.EDU
RTIMAGES ADDE.UNIDATA.UCAR.EDU
RTNIDS ADDE.UNIDATA.UCAR.EDU
RTNOWRAD ADDE.UNIDATA.UCAR.EDU
RTPTSRC ADDE.UNIDATA.UCAR.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
dsinfo.k IMAGE RTIMAGES
Dataset Names of Type: IMAGE in Group: RTIMAGES
Name NumPos Content
------------ ------ --------------------------------------
ANTARCTIC 10 Antarctic IR Composite
EDFLOATER-I 10 Educational Floater
EDFLOATER-II 10 Educational Floater II
GE-IR 10 GOES-East North America IR
GE-IRTOPO 10 GOES-East IR/TOPO Composite
GE-VIS 10 GOES-East North America VIS
GE-VISTOPO 10 GOES-East VIS/TOPO Composite
GE-WV 10 GOES-East North America H2O
GEW-IR 10 GOES-East/West IR Composite
GEW-IRTOPO 10 GOES-East/West IR/TOPO Composite
GEW-VIS 10 GOES-East/West VIS Composite
GEW-VISTOPO 10 GOES-East/West VIS/TOPO Composite
GEW-WV 10 GOES-East/West H2O Composite
GW-IR 10 GOES-West Western US IR
GW-IRTOPO 10 GOES-West IR/TOPO Composite
GW-VIS 10 GOES-West Western US VIS
GW-VISTOPO 10 GOES-West VIS/TOPO Composite
GW-WV 10 GOES-West Western US H2O
MDR 10 Manually Digitized Radar
MDRTOPO 10 MDR/TOPO Composite
MOLL-IR 10 Mollweide Composite IR
MOLL-IRTOPO 10 Mollweide IR/TOPO Composite
MOLL-WV 10 Mollweide Composite H2O
RESFLOATER 10 Research Floater
DSINFO -- done
>I am assumming you have made some changes to the compiling process to get
>things working. Can you send those to me? I can send you in a separate email
>the makelog from our build/compile of 7.6 if you would like.
I just looked in my changes file to see what mods were made specifically
for DEC. I find mods to:
makefile
mcaget.for
mcimagem.c
tclcomp.sh
mccomp.sh
The change to makefile was the addition of a VENDOR macro that is defined
to be '-vendor'. This makes our distributions default to use of vendor
compilers instead of gcc/f2c.
The change in tclcomp.sh was to add DEC to the list of OSes that were
supported. The change to mcaget.for is described as follows:
mcaget.for SSEC 7.60 version with mods
copy FORM to CFORM and test CFORM(1:2) instead of FORM
this hack makes IMGDISP, etc. work on DEC OSF/1
The code mods themselves look like:
...
CHARACTER*12 CID ! <<<<< UPC add 980420 >>>>>
This mod is for the addition of an ID= keyword for all of the IMG
applications. We added ID= to support the WIS NIDS ADDE servers that
I wrote. This mod should not affect you.
...
C---------Determine data format
CFORM=FORM ! <<<<< UPC add 961026 >>>>>
CSTYP=' '
stretch=0
IF(CFORM(1:2).EQ.'I1') THEN ! <<<<< UPC mod 961026 >>>>>
IFORM=1
ELSEIF(CFORM(1:1).EQ.' ') THEN ! <<<<< UPC mod 961026 >>>>>
IFORM=0
ELSEIF(CFORM(1:2).EQ.'I2') THEN ! <<<<< UPC mod 961026 >>>>>
IFORM=2
ELSEIF(CFORM(1:2).EQ.'I4') THEN ! <<<<< UPC mod 961026 >>>>>
IFORM=4
ELSE
IRET=-37
c CFORM=FORM ! <<<<< UPC mod 961026 >>>>>
CALL EDEST('MCAGET cant do format '//CFORM,0)
GOTO 1000
As you can see from my modification tags, I have been making the same
change since October of 1996.
...
C------Default values for server keywords
CBAND=' '
CLMAG=' '
CEMAG=' '
CCCCAL=' '
CDOC = ' '
ctrace = 'TRACE=0'
CT1='X'
CT2='X'
CT3='I'
CDAY=' '
CAUX=' '
CID=' ' ! <<<<< UPC mod 980420 >>>>>
Again, the CID mod is for support of our ID= keyword.
The change to mccomp.sh was the inclusion of the '-ieee_with_inexact'
flag in ccopts:
OSF1)
# use the OSF1 vendor compilers
case ${vendor:-$MCIDAS_CC} in
?*)
cc=cc
# The -DFUNCPROTO=15 is to get the X header files to include
# their prototype information.
# Maybe add -varargs too?
# Using -warnprotos is good, except that some macros in
# <ctype.h> use functions that have no prototypes.
ccopts="-std -DFUNCPROTO=15 -ieee_with_inexact"
;;
esac
case ${vendor:-$MCIDAS_F77} in
?*)
clopts=
fc=f77
fcopts=
flopts=
# If the main program is written in Fortran, we let the system
# do its thing. Otherwise, must tell the compiler not to use
# its definition of main.
case $fp_opt in
?*) ;;
*) flopts="$flopts -nofor_main"
;;
esac
fc_does_INCLUDE_search=true
;;
esac
;;
I bet that the '-ieee_with_inexact' flag will not be recognized by gcc;
it was added for the DEC C compiler.
>Thanks for your help.
I am betting that the mods I list above do not solve your problem, but
I will be interested in finding out if they have any positive affect on
your installation.
Have you tried building using the Digital compilers? I have not tried
building using gcc/f2c on any platform except Sun Solaris x86 and Redhat
5.2 Linux.
>regards,
If the above changes don't help, could you send along your McIDAS-X make
logfile so I can take a look? Thanks.
Tom
>From address@hidden Thu Jul 1 10:27:44 1999
Tom,
I will impliment your changes and remake using the vendor compilers first
then gcc/f2c if -v does not work.
thanks,
Randy