View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

Problem compiling a task on MacIntel

rrg wrote on Nov 14, 2006

I'm trying to compile a task I had running on PPC Macs. I modified the path to the libraries to /iraf/irafbin/noao.bin.macintel/libsmw.a. When I run mkpkg I get

check out file `libpkg.a = /Users/gal/Work/iraf/scripts/libpkg.a'
xc -c -w wrspect.x
wrspect.x:
Fatal compiler error: Cannot execute xpp.e
Fatal compiler error: Cannot execute rpp.e
ar r /Users/gal/Work/iraf/scripts/libpkg.a wrspect.o
ar: wrspect.o: No such file or directory
ranlib /Users/gal/Work/iraf/scripts/libpkg.a
Updated 1 files in libpkg.a
check file `libpkg.a' into `../'

I checked and xpp.e and rpp.e are present in /iraf/iraf/unix/bin.macintel and they are executable. Any help would be appreciated.

Mike Fitzpatrick wrote on Nov 14, 2006

My guess is that you might have an old architecture definition (i.e. IRAFARCH or hbin environment variables) from your PPC days, in your .cshrc file. Grep for 'macosx' in these files and double-check the permissions on the .e files in $iraf/unix/bin.macintel as well as each of the directories in the path to it (i.e. if the $iraf dir isn't world readable the executables in the tree under it can't be read either).

Note that compiling with "xc -dv foo.x" will print the details of what's happening and show you the paths to the xpp/rpp being used. Hope this helps.

Cheers,
-Mike

James Turner wrote on Nov 14, 2006

Having switched to IRAF 2.13 beta 2, I'm now having a similar problem compiling things. I get the same compiler errors about xpp.e and rpp.e with mkpkg, as well as the message "/usr/bin/ld: cannot find -lcompat" from xc.

I have IRAFARCH set to "linux" and /iraf/iraf/unix/bin.linux/libcompat.a exists and is readable. Likewise, xpp.e and rpp.e exist and are readable and executable. I'm not sure why these are not being found. Could I be missing an environment variable setting?

Doing "xc -dv" gives the following output:
debug: xpp.e -R t_test.x
Fatal compiler error: Cannot execute xpp.e
debug: rpp.e t_test.r >t_test.f
Fatal compiler error: Cannot execute rpp.e
gcc -Wl,--defsym,mem_=0 -o T_t_test.e -v -I/iraf/iraf/unix/hlib/libc /iraf/iraf/bin.linux/libmain.o /iraf/iraf/bin.linux/libex.a /iraf/iraf/bin.linux/libsys.a /iraf/iraf/bin.linux/libvops.a /iraf/iraf/unix/hlib/libos.a -lg2c -lm -lcompat
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
 /usr/lib/gcc/i486-linux-gnu/4.0.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o T_t_test.e /usr/lib/gcc/i486-linux-gnu/4.0.3/../../
../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.0.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.0.3 -L/usr/lib/gcc/i486-linux-gnu/4.0.3 -L/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib -L/usr/lib/gcc/i486-linux-gnu/4.0.3/../../.. -L/lib/../lib -L/usr/lib/../lib --defsym mem_=0 /iraf/iraf/bin.linux/libmain.o /iraf/iraf/bin.linux/libex.a /iraf/iraf/bin.linux/libsys.a /iraf/iraf/bin.linux/libvops.a /iraf/iraf/unix/hlib/libos.a -lg2c -lm -lcompat -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.0.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crtn.o
/usr/bin/ld: cannot find -lcompat
collect2: ld returned 1 exit status

Just now I tried setting XC_LFLAGS to "-L /iraf/iraf/unix/bin.linux/", which has got rid of the linker error, but xc then still gives me "Fatal compiler error: Cannot execute xpp.e" instead (and likewise for rpp.e). Obviously there must be a problem with a path setting somewhere else...

I'd appreciate it if someone can tell me where to set the path needed for xc to find the files in unix/bin.linux. Suggestions as to what I might have done wrong to end up with it set incorrectly would be better still.

Thanks,

James.

Mike Fitzpatrick wrote on Nov 14, 2006

James,

Your first post mentions macintel, but the latest refers to linux -- which platform is it? The Mac systems (ppc or intel) do not require the -lcompat and the proper IRAFARCH for a Mac Intel system is 'macintel', setting it to 'linux' would certainly explain the problem. One thing to try is to simply type 'xpp' at the unix prompt and see if you get a more informative host error message.

-Mike

James Turner wrote on Nov 14, 2006

Hi Mike,

Sorry for the confusion. I am not the author of the original post. My problem looked like it might be the same as the one I found here, so I added the question to this thread, rather than starting a new one. In fact, my architecture is linux (Ubuntu 6.06), whereas the previous poster's architecture was macintel.

If I type "xpp" at the Unix prompt, nothing happens (the xpp program starts).

Thanks,

James.

Mike Fitzpatrick wrote on Nov 14, 2006

Ahh. In that case, I had a look at the Ubuntu writeup mentioned in another thread an noticed they say to 'mv' the iraf#unix/bin.redhat contents to the bin.linux directory.....this should probably say 'cp' instead. The reason is that the path to the hbin$ is set at compile time as iraf$bin.<arch>: The bin.redhat xc.e is expecting to look in the bin.redhat directory, but you've moved all this to bin.linux and so files like xpp.e cannot be found.

-Mike

James Turner wrote on Nov 14, 2006

Thanks, Mike!

I hadn't thought of that, but it makes sense (and works) now. I'm not sure whether I did a 'mv' or whether I let the install script remove the binaries for other architectures, but either way the effect is the same.

James.

Last post on Nov 14, 2006