20030617: compiling user server under Linux (cont.)

>From: "=?ISO-8859-1?Q?Marianne=20K=F6nig?=" <address@hidden>
>Organization:  EUMETSAT
>Keywords:  200306160918.h5G9IYLd025247 McIDAS-X Linux libf2c.a

Hi Marianne,

>I am sorry to say that - but it did not workl. I am actually using the
>/usr/lib/local/libf2c.a   (see my error message below), and this is the only
>libf2c I have on my system.

This is very strange.  The only times I have seen a link failure like
the one you sent previously was when the shared f2c library was being
searched instead of the static one.  MAIN__ is only found in the static
library.

>I did an ar -t libf2c.a and it listed a main.o as an entry. I have a
>feeling it has to do with this underscore business (that for some reason
>mcidas expects a main_.o (?)).
>
>Because:
>I also use a c subroutine that my msgsadir.f calls (called read_filelist), and
>in the HP source code the routine simply starts with
>
>void read_filelist_   ....

The inclusion of the trailing underscore is typically done for C routines
that are callable by Fortran routines since Fortran is typically expecting
the trailing underscore.

>My Linux then complained that it did not find read_filelist__  (2 underscores),
>and I never undrstood where the second udnerscore comes from.

Compiler flags can be set to use one or two trailing underscores.

>So I simply changed (within my C code) the read_filelist_ to read_filelist__ .

I don't think that this is the correct approach.  You should change this
back to a single trailing underscore.

>And after that this complaint about main__ (again 2 underscores) came up.
>Any more ideas?

Yes, change read_filelist__ back to read_filelist_ and then set
the following Unix environment variables:

CC=gcc
CPPFLAGS=-Df2cFortran
FC=mcfc
CXX=
STRIP=-Wl,-s
export CC CPPFLAGS FC CXX STRIP

(of course, use the appropriate syntax for the shell you are running in).

and then retry your build.

Here is the real problem from my end.  I do not use the SSEC build
procedures, and I rarely use the gcc/f2c/mcfc compiler combination (I
did build v2003 on RedHat 7.3 Linux using this combination after our
exchange yesterday, and things worked fine).

My approach would be to add my own server build to the McIDAS makefile
(~mcidas/mcidas2002/src/makefile) and then run 'make' by hand.  The
problem with this approach is that you are forced into modifying the
SSEC makefile each time you upgrade.  This can be a problem unless you
really know what you are doing.  I have to do this anyway, since I have
to make lots of modifications to the SSEC distribution to produce my
own.

A different and better approach would be for you to setup a makefile of
your own that would build all of your local code in a separate
directory.  I helped one of my sites do this in their
~mcidas/mcidas/src directory.  I setup their system to install their
binaries in the ~mcidas/mcidas/bin directory (and local data files in
the ~mcidas/mcidas/data directory).  I then had to adjust their PATH to
include ~mcidas/mcidas/bin _before_ ~mcidas/bin and to include
~mcidas/mcidas/data in their MCPATH _before_ ~mcidas/data.  Now, then
can develop their own routines and build them running make by hand:

<login as 'mcidas'>

cd mcidas/mcidas/src

<modify routines as needed; add build of new ones to the Makefile which
is in this directory (that I created using ~mcidas/mcidas2002/src/makefile
as a guide>

make <routine_name.k>

>Or how can I change my environment to use the gcc/g77 instead of gcc/f2c/mcfc?

If you were using my distribution of McIDAS, this would be done by
setting VENDOR= in the makefile to -g77, but the SSEC v2002 version of
mccomp.sh is not setup to handle this (I think it is in v2003).  I have
been working to get the SSEC distribution to look as much like mine as
possible.  This is a constant struggle, however, since there are
different ideas about how things should be done.

>I hate myself.

You are _so_ close to being done -- really --.  Don't despair now!

>Another wine for you.

Yahoo :-)

Tom