iraf.net

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? https://iraf.net/phpBB2/viewtopic.php?t=85508Many thanks,James.

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[code:1:ed9a560815]
unix% setenv tables /iraf/extern/tables/
unix% cd /iraf/extern/tables
unix% mkpkg -p tables linux
unix% mkpkg -p tables update
[/code:1:ed9a560815]
Hope this helps.Cheers,
-Mike

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.clI 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.

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 NOVOSCheers,James.

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:
[quote:08df8ac7bb]+ 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
[/quote:08df8ac7bb]
Then XC:
[quote:08df8ac7bb]+ 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
[/quote:08df8ac7bb]
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.

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.

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.

The error "missing colon in case or default label" is being triggered by case statements with more than one case value, ie.:[code:1:96d2e1d701]case A, B:
blah;
[/code:1:96d2e1d701]
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:

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 inftp://iraf.noao.edu/pub/fitz/hbin_2122.linuxDownload 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

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.

[quote:3d59971ce2]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? [/quote:3d59971ce2]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

Hello,I'm having a problem with tables. I received an error message :ERROR on line 477: Cannot open connected subprocess (ttools$x_ttools.e)I'm using Ubuntu (Edgy). Might it be some installing problem? Maybe the binaries.
I appreciate any help.

The error usually means that either the binaries aren't installed, or are installed in the wrong directory (for Ubuntu this should be tables$bin.linux). A common mistake is to compile a package from source but forget to reconfigure the package for the architecture first, this leaves the binaries in the package 'bin.generic' directory (which should always be empty). If the binaries are there you can move them to the proper directory, a better solution is to re-start from the source installation and remember to do a "mkpkg -p tables linux" to set the arch before compiling.-Mike

Hello,[i:b97de26005]The error usually means that either the binaries aren't installed, or are installed in the wrong directory (for Ubuntu this should be tables$bin.linux). [/i:b97de26005]Yes, they are installed like this (tables$bin.linux)[i:b97de26005]A common mistake is to compile a package from source but forget to reconfigure the package for the architecture first, this leaves the binaries in the package 'bin.generic' directory (which should always be empty). [/i:b97de26005]This package (bin.generic) is empty.[i:b97de26005]If the binaries are there you can move them to the proper directory, a better solution is to re-start from the source installation and remember to do a "mkpkg -p tables linux" to set the arch before compiling. [/i:b97de26005] Should I restart from the source installation? If yes, what does this mean? and how can I do this? Thanks a lot.

Hey Mike,terminal@terminal:/iraf/iraf/bin.linux$ lscl.e libex.a libmemdbg.a libxtools.a x_plot.e
IB.LNUX.X86 libgks.a libncar.a OBJS.arc.Z x_proto.e
irafks.e libgsurfit.a libnlfit.a x_dataio.e x_sgikern.e
libbev.a libimd.a libsgi.a x_images.e x_softools.e
libc.a libimfort.a libslalib.a x_imdkern.e x_stdgraph.e
libcur.a libiminterp.a libstg.a x_lists.e x_system.e
libcurfit.a libinterp.a libsurfit.a x_mkttydata.e x_tv.e
libdeboor.a libllsq.a libsys.a x_ncar.e x_utilities.e
libds.a libmain.o libvops.a x_obsolete.ex_ttools.e should be at (iraf/iraf/bin.linux)? The error message indicate that x_ttools.e should be at ttools right? (ttools$x_ttools.e) Well, there's nothing like that there.
In (/iraf/extern/tables/pkg/ttools) there's something like (x_ttools.x).
P.S.: As you can see I'm still learning about Ubuntu and IRAF.

Livia,External packages have their own bin directories, in this case you should look for the x_ttoole.e binary in /iraf/extern/tables/bin.linux. The error message is confusing I agree, what happens is that the binary isn't found in the normal bin directory, the systems looks in the source dir for it and when it can't find it prints the error with that path. It sounds like you've installed the sources corrently, check the contents on /iraf/extern/tables/bin.linux and if empty unpack the binaries there or do the 'mkpkg -p tables linux' command before building from source.Cheers,
-Mike

Hi Mike,[i:f273f57f2c] /iraf/extern/tables/bin.linux[/i:f273f57f2c] was empty indeed. The binaries were in [i:f273f57f2c]/iraf/extern/tables/bin.redhat[/i:f273f57f2c]. I've just moved them to [i:f273f57f2c]/iraf/extern/tables/bin.linux[/i:f273f57f2c] . And did the same to the [i:f273f57f2c]stsdas[/i:f273f57f2c] binaries. Now everything is working fine. Thanks a lot for your time. Lívia

Hey Mike, I have another doubt, if you can help me.I've received an ERROR on line 200: Attempt to access undefined local variable 'p'. Can you tell me what does this mean?
Thanks!!

Basically it just means a script task is trying to use a variable 'p' that hasn't been initialized (e.g. not set explicitly, a failed read, etc). Without knowing the task I can't say much more than that, but look at the script (if it's your own) for how/where that variable gets used.-Mike

Hello Mike, Well, after changing all the files from [i:0589301b75]redhat.bin[/i:0589301b75] to [i:0589301b75]linux.bin[/i:0589301b75] at [i:0589301b75]stsdas[/i:0589301b75], [i:0589301b75]tables[/i:0589301b75] and [i:0589301b75]ctio[/i:0589301b75] I'm still receiving the error message:
[i:0589301b75] ERROR on line 477: Cannot open image .(../ )
( ) quickpol[/i:0589301b75] It worked fine, as I told you before, but now ...... well ...sometimes (rarely) it works, when it wants to. I'm using a package called [i:0589301b75]pccdpack[/i:0589301b75] (a polarimetric data reduction package), the routine is called [i:0589301b75]quickpol[/i:0589301b75]. I have already talked to the developer of this package (a colleague) and he said that this might be a problem in IRAF installation not in the package. I think the problem is something about IRAF on Ubuntu. Everybody I know that uses this package (and routine) has no problem using another linux (like Fedora or something). Maybe you can help me.

Lívia.

Livia,I was able to find a version of pccdpack; This is simply a script package however there is one compiled binary in the pccdpack$pccd directory. What is unusual is that this binary isn't installed in a bin directory of any kind, but the path to it is declared as a script parameter. You can try running the binary directly to see if it works, and see the readme to recompile it if not. If the binary works as is, then check the task parameters to be sure you have the right path.I don't understand your comment that it 'rarely' works, if the installation is broken then it should never work. Hope this helps.-Mike

Yeah Mike, that's weird...

Well, I didn't run the binary directly because I don't know how to do this. I've just recompiled it.[b:abe021436c][i:abe021436c]
I don't understand your comment that it 'rarely' works, if the installation is broken then it should never work. [/i:abe021436c][/b:abe021436c]Ok. I've tried to run the package and the task [i:abe021436c]quickpol[/i:abe021436c] (after the re-compilation) and the same error 477 appeared. I've logged out, re-opened IRAF and tried again. It has worked just fine. :I don't know. Maybe the sequence for oppening IRAF, ds9 from terminal or xgterm ... has something to do with it...??????? (I'm sorry if it's stupid but as I told you before I'm knew on IRAF and Ubuntu and have no idea of what can and can't be possible.)
Well... It's working .... so far.
If I get the same error again I will let you know. Thank's a lot.

Lívia.

Hello Mike, I'm still getting that same 477 cannot open image error.I tried to reinstall ds9 following some steps at https://docs.astro.columbia.edu/wiki/ds9 to get saods9 for ubuntu .I create a folder with saods9 files : [b:ee26724d81][i:ee26724d81]terminal@terminal:~/src/saods9$ ls
saods9-4.0b7 saods9_4.0b7-1.3ubuntu1_i386.build
saods9_4.0b7-1.3ubuntu1.diff.gz saods9_4.0b7.orig.tar.gz
saods9_4.0b7-1.3ubuntu1.dsc
[/b:ee26724d81]
[b:ee26724d81]terminal@terminal:~/src/saods9$ cd saods9-4.0b7terminal@terminal:~/src/saods9/saods9-4.0b7$ ls
acknowledgement funtools-1.3.0b9 Makefile make.solaris sla
ast-3.5 html make.hpux make.solaris64 tkmpeg
bin htmlwidget make.include make.windows wcssubs-3.5.6
checkdns iis make.linux man win
COPYING include make.linux64 mktclapp xpa-2.1.6
copyright lib make.linuxppc README
debian make.alpha make.pkgs saotk
ds9 make.darwin make.sgi share[/i:ee26724d81][/b:ee26724d81]
Now when I try to run ds9 from terminal I receive the message :[b:ee26724d81][i:ee26724d81]terminal@terminal:~$ ds9
bash: /usr/local/bin/ds9: impossible to execute binary file[/i:ee26724d81][/b:ee26724d81]Something is missing but I can't figure it out. I need to make the installation of the new package. The link says to do something like [i:ee26724d81]extract the saods9-4.0b7-1 package into the new directory, and run:[/i:ee26724d81] [b:ee26724d81][i:ee26724d81]patch -p1 <../breezy-port.diff[/i:ee26724d81] [/b:ee26724d81] (I have a saods9_4.0b7-1.3ubuntu1.diff file at :~/src/saods9)followed by:[b:ee26724d81] [i:ee26724d81] debuild -uc -us [/i:ee26724d81][/b:ee26724d81]resulting in a installable deb file. Something like [i:ee26724d81]saods9_4.0b7-1.dkgbreezy0_i386.deb[/i:ee26724d81]That I should install as :
[b:ee26724d81][i:ee26724d81]sudo dpkg --install saods9_4.0b7-1.dkgbreezy0_i386.deb [/i:ee26724d81][/b:ee26724d81]

*Of course the resulting deb file from diff file is not the same as saods9_4.0b7-1.dkgbreezy0_i386.deb since the diff file isn't breezy-port.diff but
saods9_4.0b7-1.3ubuntu1.diffWell, my problem is that I have to get this deb file and install it to make the binary file executable. Right???!!!It's a mess.... Maybe it was a bad idea to consider this script to re-install ds9 !!!??Can you help me? (Again) Lívia.

Livia,The pre-built binary at ftp://sao-ftp.harvard.edu/pub/rd/ds9/linux/ds9 (v4.0b10) works just fine under Ubuntu 6.10. Just download, make executable and install in some place like /usr/local/bin (or /bin, or ....)-Mike

Hello Mike, Now I'm having a problem with zerocombine .
When I try to
[i:ca2286f21d] cc>zerocombine bias000*.fits ccdtype = " "[/i:ca2286f21d] I've got the message:
[i:ca2286f21d] ERROR on line 46: segmentation violation
zerocombine (input=bias000*.fits, ccdtype= )[/i:ca2286f21d] When I try to
[i:ca2286f21d] cc> zerocombine
List of zero level images to combine (bias000*.fits):[/i:ca2286f21d] I've got the message:
[i:ca2286f21d]ERROR on line 46: No images to combine
zerocombine ( )[/i:ca2286f21d]
I have read what you said about zerocombine in another topic of this forum. You said something about imagetyp. How can I access and edit it ? (if it's the case) .

Hello Problem solved. set imtype = "fits"Now when I try to run flatcombine :[i:8da32718bf] cc> flatcombine flat*.fits ccdtype = " "
ERROR on line 47: Bias section not specified or given as full image
flatcombine (input=flat*.fits, ccdtype= )[/i:8da32718bf] Should I convert all images to .imh (from .fits) or there's any other way to solve this problem? Thank you Mike.

Lívia

Livia,Please post an image header (i.e. "imhead foo.fits long+"), the task is looking for a BIASSEC keyword to define the bias section (or in some cases a 'biassec' parameter, e.g. to CCDPROC). You can use the banner bar to search the forums for similar error messages, perhaps an earlier reply will give you another hint.-Mike

Hey MIke,I'm getting the following error message when trying to run zerocombine :ERROR on line 46 : No images to combine
zerocombine ()The image type is ok and so does the image directory path. I don't know what might be wrong.Now another error : cc> zerocombine
ERROR on line 46: Image header parameter not found (exptime)
zerocombine ()P.S. : A *.fits file (the output file from zerocombine routine - Zero.fits) is generated but I can't display it on ds9.I've tried to :cc> ccdhedit bias*.fits exptime=1
ERROR: parameter 'exptime' not found Thank you. Lívia.

Livia,[quote:338f01c53c]cc> ccdhedit bias*.fits exptime=1
ERROR: parameter 'exptime' not found [/quote:338f01c53c]The keyword name and its value are two different parameters to the task, when you say 'exptime=1' it is seen as a single param and I think the CL is complainimg that there is no CL 'exptime' variable to use. Try usng "ccdhedit *.fits exptime 1" instead.As for the zerocombine problem, be sure that the IMAGETYP keyword is the same as the 'ccdtype' parameter set for the task, e.g. the default ccdtype is 'zero', be sure the IMAGETYP isn't something like 'bias'.-Mike

Hi,I've tried to use :
"ccdhedit *.fits exptime 1"And I've got:ERROR: Image header parameter not found (exptime)
The IMAGETYP keyword is the same as the 'ccdtype' parameter set for the task.bias*.fits[1050,1050][short][zero][ ]:biascc> zerocombine
List of zero level ....
ERROR on line 46: Image header parameter not found (exptime)
zerocombine ( )
Lívia.