Problem compiling tables on Ubuntu 6.06

James Turner wrote on Nov 07, 2006

Hello,

I hope it's OK to ask this here, rather than emailing STScI? It seems like it might be a more general problem.

I'm trying to compile tables under Ubuntu (mkpkg -p tables update), since there are no "linux" binaries. I am getting numerous errors about things (in tables$lib) not being found, unfortunately. I imagine they all stem from the first error, which is this:

Warning, mkpkg line 0: cannot open `tables$lib/mkpkg.inc'

In the same IRAF session that I'm trying to compile from, I can do a "page tables$lib/mkpkg.inc" and read that file with no problems.

Any suggestions? It looks like the following thread is similar, where you suggested using the redhat binaries; do you think that would be the best solution?

http://iraf.net/phpBB2/viewtopic.php?t=85508

Many thanks,

James.

Mike Fitzpatrick wrote on Nov 07, 2006

The MKPKG command is technically a foreign command and gets its definition of (in this case) 'tables' ONLY either from hlib$extern.pkg or your unix environment. PAGE on the other hand might work because 'tables' is defined on the CL command line or your login[user].cl file.

If you've defined the package in hlib$extern.pkg check the path definition and be sure there is a trailing '/'. If you defined this in your user environment you cannot compile from inside the CL, outside the CL try something like


unix% setenv tables /iraf/extern/tables/
unix% cd /iraf/extern/tables
unix% mkpkg -p tables linux
unix% mkpkg -p tables update

Hope this helps.

Cheers,
-Mike

James Turner wrote on Nov 07, 2006

Hi Mike,

Thanks for the advice. My definition of tables in hlib$extern.pkg is as follows, which seems OK:

reset extern = /iraf/extern/
[...]
reset tables = extern$tables/
task tables.pkg = tables$tables.cl

I tried compiling outside the CL in any case. That did in fact get rid of the mkpkg error, but I STILL get all the subsequent errors, such as the following:

warning: library `libdisplay.a' not found
Warning, mkpkg line 11: dependency file `<curses.h>' not found
[...]
Error on line 1 of addch.x: cannot find include file
[...]
Error on line 2 of addstr.x: cannot find include file
[... etc ...]

The files that are not found are from tables$lib. I had assumed that mkpkg.inc not being found was the cause of these later compile errors, but maybe it isn't.

I hope I'm not overlooking anything obvious. Tables is definitely in extern$tables/ (and is not being overriden elsewhere). I even tried changing it from a symbolic link to a real directory called "tables", but it didn't help. Anyway, I'll be grateful if you have any more suggestions off the top of your head... I'd be happy to send more info if it helps.

Thanks,

James.

James Turner wrote on Nov 07, 2006

I had overlooked this message at the very start of the compilation process. I'm just reading up on what it means, but it sounds like it might be relevant:

HSI is compiled NOVOS

Cheers,

James.

James Turner wrote on Nov 07, 2006

So, in response to the "NOVOS" message, I tried bootstrapping IRAF, as described in section 3.8 of the site managers' guide. Having followed the instructions in the install guide, I'm not sure why I'd have to bootstrap IRAF this time and not on previous occasions, but it seemed worth a try. It looks like my /iraf/iraf/bin was not originally pointing to bin.linux, BTW.

The result is that most of the HSI executables have been successfully replaced with new versions, but I encountered errors specifically with mkpkg and xc.

First of all mkpkg:

+ gcc -c -O -DLINUX -DPOSIX -DSYSV -w -Wunused char.c fdcache.c fncache.c host.c main.c pkg.c scanlib.c sflist.c tok.c
In file included from host.c:12:
extern.h:4: error: array type has incomplete element type
+ gcc main.o char.o fdcache.o fncache.o host.o pkg.o scanlib.o sflist.o tok.o /iraf/iraf/unix/hlib/libboot.a /iraf/iraf/lib/libsys.a /iraf/iraf/lib/libvops.a /iraf/iraf/unix/hlib/libos.a -o mkpkg.e
gcc: host.o: No such file or directory
+ mv -f mkpkg.e ../../hlib
mv: cannot stat `mkpkg.e': No such file or directory

Then XC:

+ gcc -c -O -DLINUX -DPOSIX -DSYSV -w -Wunused xc.c
xc.c: In function `addflags':
xc.c:1211: error: address of register variable `lflag' requested
[... error repeated 8x ...]
+ gcc xc.o /iraf/iraf/unix/hlib/libboot.a /iraf/iraf/lib/libsys.a /iraf/iraf/lib/libvops.a /iraf/iraf/unix/hlib/libos.a -o xc.e
gcc: xc.o: No such file or directory
+ mv -f xc.e ../../hlib
mv: cannot stat `xc.e': No such file or directory

When installing IRAF, I used the current as.pcix.gen.gz, ib.lnux.x86.gz and nb.lnux.x86.gz archives from http://iraf.noao.edu/iraf/ftp/iraf/v212/PCIX/.

Does this help understand the problem, or am I way off mark in investigating the NOVOS thing?

Thanks,

James.

James Turner wrote on Nov 07, 2006

Sorry for all the posts, but I notice something that makes me wonder whether this is a problem with the IRAF files for the "linux" architecture. My compilation problem (failing to find files in lib directories) is not specific to tables, BTW; it appears when I try to compile other packages as well.

I see that as.pcix.gen.gz contains iraf/unix/bin.arch/ binaries for several different architectures. For most of these architectures, the mkpkg.e binary has a date stamp of 30-31 December 2003, but for linux and linuxppc, the date is 2 February 2004.

Is there any chance that the other architectures, such as "redhat", are distributed with VOS binaries, whereas the distributed "linux" binaries were rebuilt at some point without the second bootstrap stage? Could that cause my problem? If so, I'd be quite surprised that no-one had reported this by now, but I suppose "linux" is less widely used than "redhat", isn't it?

Thanks,

James.

James Turner wrote on Nov 07, 2006

OK: I found a workaround for the general compilation problem, but still haven't managed to build tables yet...

After not much progress on this, I tried changing "setenv CC gcc" to "setenv CC gcc-3.4" in iraf/unix/hlib/irafuser.csh (NB. this requires having the Ubuntu/Debian package "gcc-3.4" installed). Using this older GCC version, I was able to finish bootstrapping IRAF without errors. Now the message "HSI is compiled NOVOS" has gone away and I seem to be able to compile things in Ubuntu :-). That's certainly a big improvement!

Unfortunately, I'm still getting various errors when trying to compile tables, apparently originating with the SPP code itself (eg. "missing colon in case or default label" from omniread.x and other files).

Cheers,

James.

James Turner wrote on Nov 07, 2006

The error "missing colon in case or default label" is being triggered by case statements with more than one case value, ie.:

case A, B:
  blah;

I'm puzzled as to why my xc compiler objects to this. I thought it was valid SPP syntax. Presumably it must be, or else tables would fail to compile on all architectures? I'd appreciate any insights.

Anyway, I finally managed to build tables by going through these errors and expanding out all multiple-value case statements in the source into multiple, separate statements. This was straightforward except one case (vexcompile.x) which had goto labels in the middle. Doing this for dozens of files is a major pain, however, so I'd really like to find out why the problem occurs before starting on compiling stsdas and other packages!!!

The files affected are the following:

James.

Mike Fitzpatrick wrote on Nov 07, 2006

Hi James,

Sorry to drop off the thread, I've been travelling and off the net last week. This is a known problem (i.e. the NOVOS HSI in V2.12.2) with the linux architecture HSI binaries. Installing from the V2.12.2a sources (i.e. see http://iraf.noao.edu/iraf/PCIX/patch2a/as.pcix.gen.gz) should give you correct HSI binaries, else download the files in

ftp://iraf.noao.edu/pub/fitz/hbin_2122.linux

Download in binary mode and replace the contents of your $iraf/unix/bin.linux / directory with these. Alternatively, the prebuilt RedHat binaries should work on your system so long as you install them in the package 'bin.linux' directory.

A NOVOS build disables some features, in this case things like logical pathname resolution (i.e. the 'tables$'). The problem you mention with GCC and the swith labels are things that came up in the V2.13 ports and are fixed in that system (e.g. the switch labels is due to an uninitialized variable in the RATFOR translator) so using the V2.13 systems, and/or pre-built redhat binaries for packages, is another possibility (again you may need to use redhat binaries in a bin.linux directory). Hope this helps.

Cheers,
-Mike

James Turner wrote on Nov 07, 2006

Hi Mike,

Thanks for your explanations, especially regarding the switch labels.

For some reason I was convinced that the main 2.12.2 distribution already includes the 2a patch, but apparently I got that wrong. Apologies if I have been asking about problems that were already solved in the latest version.

Is there no significant difference between "redhat" and "linux" IRAF binaries in general? I had assumed that the former are redhat-specific since they are distributed separately from the generic "linux" binaries -- but maybe they are just called "redhat" by default because they were built on a redhat system?

I may try switching to 2.13 anyway, then I can be a guinea pig for running the Gemini package under it :-).

Cheers,

James.

Mike Fitzpatrick wrote on Nov 07, 2006

Is there no significant difference between "redhat" and "linux" IRAF binaries in general? I had assumed that the former are redhat-specific since they are distributed separately from the generic "linux" binaries -- but maybe they are just called "redhat" by default because they were built on a redhat system?

When the Linux port was first done the differences were real, e.g. major differences in the GCC/Glibc used by different distributions, however this is not so much the case any longer and the reason we're looking at doing a single Linux architecture. In most cases, the current 'redhat' binaries will run on recent linux distros of any flavor so long as they are in the bin directory expected by the system. Undoing this 'expectation' by removing the architectures isn't hard, but it isn't necessarily fun either.

-Mike