[McIDAS #LDE-412096]: setting up mcadde account in Suse 10.1

Hi HP,

> About Ougadougou might be some words with Volker might help. Of course I
> would very much like to be physically there (or at least with VISITview?).

In the CC to Volker on the reply to Henc I suggested that it would be
very valuable that you participate in the conference.  I have not
received a reply from either Henc or Volker since sending the message.

> Now back to McIDAS. I solved the yacc issue. Actually SUSE is using
> another beast, bison, the GNU parser generator. But make still is not
> successful (see attached makelog). Is it problem with lex although we
> decided that lex/flex is not necessary?

Yes, the errors I see in the makelog output are flex/lex related:

gcc  -O -O3 -fomit-frame-pointer  -lm -L/home/mcidas/mcidas2006/hdf/../zlib 
-L/home/mcidas/mcidas2006/hdf/../jpeg -o ncgen  close.o escapes.o generate.o 
genlib.o getfill.o init.o load.o main.o ncgentab.o ../libsrc/libmfhdf.a 
../../hdf/src/libdf.a -ljpeg -lz=20
ncgentab.o: In function `main':
ncgentab.c:(.text+0x0): multiple definition of `main'
main.o:main.c:(.text+0x30): first defined here
/usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld: Warning: 
size of symbol `main' changed from 593 in main.o to 18 in ncgentab
main.o: In function `main':
main.c:(.text+0x55): undefined reference to `yyin'
main.c:(.text+0x7d): undefined reference to `yyout'
main.c:(.text+0x1cc): undefined reference to `yyin'
ncgentab.o: In function `yyparse':
ncgentab.c:(.text+0x5a5): undefined reference to `yylex'
collect2: ld returned 1 exit status
make[3]: *** [ncgen] Error 1
make[3]: Leaving directory `/home/mcidas/mcidas2006/hdf/mfhdf/ncgen'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mcidas/mcidas2006/hdf/mfhdf'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mcidas/mcidas2006/hdf'
make    /home/mcidas/mcidas2006/hdf:    FAILED

'yyin' 'yyout', and 'yylex' are flex related.  Here is a comment I
found on a GNU webpage:

http://www.gnu.org/software/flex/manual/html_chapter/flex_10.html

I looked at a build on one of the machines here at Unidata and see the
following representative sequence during the HDF portion of the build:

 ...

source='main.c' object='main.o' libtool=no \
depfile='.deps/main.Po' tmpdepfile='.deps/main.TPo' \
depmode=none /bin/bash ../../bin/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../../hdf/src -I../../hdf/src         -I../../mfhdf
/libsrc    -I../../mfhdf/port      -I../libsrc -I../../hdf/src         -I../../m
fhdf/libsrc    -I../../mfhdf/port      -I../libsrc -DNDEBUG -DHDF  -I/usr/includ
e/rpc -DNDEBUG -I/upc/mcidas/mcidas2006/hdf/../zlib -I/upc/mcidas/mcidas2006/hdf
/../jpeg  -O -Xc -xO2 -c `test -f 'main.c' || echo './'`main.c
"main.c", line 64: warning: implicit function declaration: getopt
flex ./ncgen.l
mv lex.yy.c ncgenyy.c
bison -y -d ./ncgen.y
mv y.tab.c ncgentab.c
mv y.tab.h ncgentab.h
source='ncgentab.c' object='ncgentab.o' libtool=no \
depfile='.deps/ncgentab.Po' tmpdepfile='.deps/ncgentab.TPo' \

Notice that 'flex' is run on ./ncgen.l to create lex.yy.c which is then renamed
ncgenyy.c.  Looks like flex/lex is really needed for the build to succeed.

. I then looked more carefully into makelog and discovered numerous
> warnings pointing e.g. to unknown escape sequence or precision and type
> conflicts.

There will always be a number of warnings in the makelog that have no
bearing on the outcome of the build.

> Also, at some palce "no C++ compiler" is issued, though it
> is obvious that the GNU C++ compiler is loaded.

Did you define the Linux environment variable 'CXX' to be empty
before running the build?  Really, I should ask you for how you
setup environment variables needed to build McIDAS before you started
the build.  If you are following the instructions for Unidata McIDAS,
then you would have include in 'if' clause in your shell-specific
definition file (commented upon in the first email of this sequence)
that would read environment variable definitions from the a file
in the ~mcidas/admin directory.  If you did this, then the Linux
environment variable 'CXX' would be defined to be empty, and this
will tell configure scripts used to build various portions of the
distribution to _not_ build C++ interfaces.  The reason for this
is McIDAS does not use any C++ code, so it does not need C++_ interfaces
built.

> Are these things harmful nor not?

Not.

> Sorry to bother you in continuation. With the 2005 version from SSEC und
> SUSE 9.3 there was just one snag (a single edit to change lcurses to
> ncurses) and the installation sailed.

A couple of comments are in order here:

- the Unidata distribution of McIDAS has a newer version of HDF than the
  SSEC v2005 one.  This was needed for for platforms not supported by
  SSEC's distribution.

- apparently a _full_ development environment was not installed on your
  SuSE 10.2 system.  If it had been, then you would not have run into
  the lack of X Windows include files (and libraries later in the build),
  and utilities like flex/lex would have been available

So, it looks like you need to find a flex RPM and install it.

Is there any way I could get a login to your system so I could take
a close look at things?  My access should make the troubleshooting
for the build quicker, and it would educate me about SuSE 10.2.  Thanks
in advance for considering this.

Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: LDE-412096
Department: Support McIDAS
Priority: Normal
Status: Open