rrg |
11/14/2006 03:48AM (Read 5792 times)
|
|
|
Status: offline
Registered: 09/26/2006
Posts: 4
|
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.
|
|
|
|
fitz |
11/14/2006 03:48AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
jturner |
11/14/2006 03:48AM
|
|
|
Status: offline
Registered: 12/29/2005
Posts: 165
|
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:
[code:1:e844a40fd4]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[/code:1:e844a40fd4]
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.
|
|
|
|
fitz |
11/14/2006 03:48AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
jturner |
11/14/2006 03:48AM
|
|
|
Status: offline
Registered: 12/29/2005
Posts: 165
|
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.
|
|
|
|
fitz |
11/14/2006 03:48AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
jturner |
11/14/2006 03:48AM
|
|
|
Status: offline
Registered: 12/29/2005
Posts: 165
|
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.
|
|
|
|