iraf.net

Hi,I am trying to compile an external package with IRAF 2.14.1 on a Solaris machine. Everything goes well until ...ld: fatal: file /usr/astro/iraf/iraf2.14.1/lib/libshare.a: open failed: No such
file or directory/usr/astro/iraf/iraf2.14.1/lib/libshare.a is a link to ../bin/libshare.a with bin being itself a link to bin.ssun. There are no libshare.a in bin.ssun. I compared with 2.12.2a and there was a libshare.a in bin.ssun in the previous version.Where can I get the missing libshare.a?Kathleen

Shared libraries are no longer used in the V2.14 system (we don't have enough machines to build against all possible versions of Solaris)and thus libshare.a is no longer used. The S*.e files are still distributed so they're available for older binaries but also aren't used in the current code.Which package are you compiling? Is the libshare.a referenced explicitly? If not, you may be picking up an old version of the iraf compiler.-Mike

Hi Mike,I'm just trying to compile 'color' for now. When I do a 'which xc' I get: xc: aliased to /usr/astro/iraf/iraf2.14.1/unix/bin.ssol/xc.eSo, looks like the current 2.14 compiler to me.What else should I check?

I just compiled COLOR on ssun w/ no problems. Check for a $iraf definition or an 'xc' alias in your .cshrc file, this will be used when running mkpkg/ The COLOR package hasn't changed in forever so a prebuilt binary should also work.

I am compiling from the iraf account. I am using the distributed version of .cshrc in 'local'. Of course, I fixed the file for local configuration. We are not using the /iraf/iraf construct, so if I had missed a setenv iraf somewhere, things would serious barf. Beside, the error message clearly tells me that it is looking in the 2.14 location. And as I showed, xc is aliases correctly.I did a search in the iraf source code, and I found this:unix/boot/spp/xc.c:#define SHARELIB "libshare.a"Could it be possible that the distributed version of 2.14.1 contains an xc compiled to use libshare.a?Kathleen

[quote:62cd8d6398]And as I showed, xc is aliases correctly.[/quote:62cd8d6398]Depends. If the alias is set because you source'd $hlib/irafuser.csh from your .login file you'll see that alias from the solaris prompt, but if your .cshrc defines a different $iraf or does a different alias then the shell running the XC command from MKPKG could be different.[quote:62cd8d6398]
I did a search in the iraf source code, and I found this:unix/boot/spp/xc.c:#define SHARELIB "libshare.a"
[/quote:62cd8d6398]Right, but the SHARELIB macro is only used if the "usesharelib" flag is set, and by default it is off for ssun and there is no way to turn it back on so this is never used.[quote:62cd8d6398]
Could it be possible that the distributed version of 2.14.1 contains an xc compiled to use libshare.a?
[/quote:62cd8d6398]No, I just checked.

I got things to work now. I had to add the following lines in the .cshrc:setenv iraf /usr/astro/iraf/iraf/
setenv IRAFARCH ssun
source ${iraf}unix/hlib/irafuser.cshThe irafuser.csh proved to be critical. Now my question to you Mike is if those lines needs to be in the .cshrc, then why doesn't the .cshrc distributed with the package have them? Why are those lines in the .login in $iraf/local instead of the .cshrc?Anyway, food for thoughts.Thanks for leading me to the solution. Much appreciated.Kathleen

I admit I didn't pay much attention to the .login/.cshrc file for this release, I just kept whatever was there already.MKPKG just runs a command called "xc". If you need the irafuser.csh alias to get the correct version then it probably means that either the installed version of the 'xc' command is pointing to an older iraf release, or else the path (defined in .cshrc) is pickup up the older version before a more recent one. If you have multiple versions of IRAF around keep in mind that only one is technically "installed" at a time, i.e. 'cl' command link in say /usr/local/bin will point to the script in a particular IRAF version. The same goes for xc, mkpkg, mkiraf, et al.-Mike