[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling - additional.

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
>