[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiling - additional.
- Subject: Re: Compiling - additional.
- Date: Fri, 6 Jun 2003 15:33:07 -0600
Stonie,
The MTLNUX number is "11".
from the Makeinc.linux file:
OPSYS = Linux
COPT = -DUNDERSCORE -D$(OPSYS) $(GEMINC) $(MOTIFINC)
FOPT = -fno-second-underscore $(GEMINC) $(GEMINC)/$(OPSYS)
Any C program should be compiled with -DLinux which is used
in gemprm.h to set MTMACH=MTLINUX.
Any fortran program will include the $GEMPAK/include/Linux/MCHPRM.PRM file
which is a link to $GEMPAK/include/MCHPRM.Linux.
If you go to any program file (like gpmap.f which includes GEMPRM.PRM
and do a write(*,*) 'MTMACH ', MTMACH
or nmap.c and printf("MTMACH %d\n",MTMACH);
You should get "11".
If not the above, then I'd look for anyway the MCHPRM.PRM file in the
$GEMPAK/include/Linux directory isn't being used....probably if
you have a MCHPRM.PRM in the -I search path first.
Steve Chiswell
On Fri, 6 Jun 2003, Stonie R. Cooper wrote:
> Chiz,
>
> This is going to drive me nuts - but I'm sure you've had those times.
>
> The Makeinc.linux is getting picked up. I'm trying to find a good place in
> the code to do a print/write statement to make absolutely sure that the
> machine type is set to little endian.
>
> Incidently, no errors (except in Garp - I figured that one out already) on
> compile. What happens is the apps can't read any map files or image files,
> and the decoders all bomb out. As an example, if I do gpmap, and just leave
> the defaults and *run*, I get:
>
> [GEMPLT -35] NMAPFR - Map file read error.
> [GG -7] No map drawn.
>
> It may have nothing to do with the endian - it's just my guess based on that
> fact I've never had this problem before, and it seems to follow data that is
> endian specific.
>
> Anyway - if you think of an *easy* place for me to but a write(f77) or
> printf(c) to check this . . . let me know. Have a good weekend!
>
> Stonie
>