compiling/linking spp
rclark wrote on Jan 13, 2011
I just got iraf 2.15 64 bit linux installed on my system. Well,
probably. I get a normal looking motd and cl prompt. Haven't
tried to exercise it much.
I'm trying to compile a simple spp program.
I got this message:
ecl> xc bittest.x
bittest.x:
sys_runtask:
t_bittest:
bittest.f:
sysruk:
tbittt:
link:
/usr/bin/ld: cannot find -lcompat
collect2: ld returned 1 exit status
ecl>
In the old installation (2.13) I find
iraf/pkg/ecl/readline/compat.c
and
iraf/unix/bin.redhat/libcompat.a
But in the 2.15 tree bin.linux64 does not have that library.
There is a compat.c file in the ecl source directory.
Is there a way to check from within a cl session which xc and
link commands are being used? I know there are several symlinks
normally normally installed in /usr/bin/local or other system areas
that a regular iraf user doesn't have permissions to change. I
think I've played the necessary games with aliases and my path
statement to address this.
Richard Clark
probably. I get a normal looking motd and cl prompt. Haven't
tried to exercise it much.
I'm trying to compile a simple spp program.
I got this message:
ecl> xc bittest.x
bittest.x:
sys_runtask:
t_bittest:
bittest.f:
sysruk:
tbittt:
link:
/usr/bin/ld: cannot find -lcompat
collect2: ld returned 1 exit status
ecl>
In the old installation (2.13) I find
iraf/pkg/ecl/readline/compat.c
and
iraf/unix/bin.redhat/libcompat.a
But in the 2.15 tree bin.linux64 does not have that library.
There is a compat.c file in the ecl source directory.
Is there a way to check from within a cl session which xc and
link commands are being used? I know there are several symlinks
normally normally installed in /usr/bin/local or other system areas
that a regular iraf user doesn't have permissions to change. I
think I've played the necessary games with aliases and my path
statement to address this.
Richard Clark
Mike Fitzpatrick wrote on Jan 13, 2011
The libcompat.a is no longer required. What's probably happening is that you are calling the older version of XC that still adds that to the link line.
The XC command is declared as a foreign task if you're compiling under the CL, and is installed as a symlink when you run the install script. If you haven't run the install script to make v2.15 the default then you're still picking up the old binary. Note also that there is an alias for 'xc' defined in the hlib$irafuser.csh script which you might be sourcing from your .cshrc file. A "cl> !which xc" will tell you whether this is an alias or a path to the command. Since you're trying to link linux64 you can't simply copy the old library, however you might try creating an empty file in iraf$unix/bin.linux64/libcompat.a to resolve the link request.
The XC command is declared as a foreign task if you're compiling under the CL, and is installed as a symlink when you run the install script. If you haven't run the install script to make v2.15 the default then you're still picking up the old binary. Note also that there is an alias for 'xc' defined in the hlib$irafuser.csh script which you might be sourcing from your .cshrc file. A "cl> !which xc" will tell you whether this is an alias or a path to the command. Since you're trying to link linux64 you can't simply copy the old library, however you might try creating an empty file in iraf$unix/bin.linux64/libcompat.a to resolve the link request.
Last post on Jan 13, 2011