View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum ↗

iraf-v216 · Code · Issues (50) · Pull requests (81)

iraf.net Issue #32

closed closed RobSteele49 opened this issue on 2017-05-04 · 5 comments


RobSteele49 commented on 2017-05-04

My ‘hack’ to fix this is to just remove these links and recreate them early in the make process. But, this is really not a long term fix. I’m wondering if someone else has seen this and if there is a long term fix?

ls -lt bytmov.c d1mach.f i1mach.f r1mach.f

lrwxrwxrwx 1 steele steele 27 May 4 09:18 bytmov.c -> /iraf/iraf/unix/as/bytmov.c
lrwxrwxrwx 1 steele steele 29 May 4 09:18 d1mach.f -> /iraf/iraf/unix/hlib/d1mach.f
lrwxrwxrwx 1 steele steele 29 May 4 09:18 i1mach.f -> /iraf/iraf/unix/hlib/i1mach.f
lrwxrwxrwx 1 steele steele 29 May 4 09:18 r1mach.f -> /iraf/iraf/unix/hlib/r1mach.f
steele@steele-VirtualBox:~/git/iraf-v216/sys/osb$

At least the directory /iraf/iraf doesn’t exist on my system.

Fixed the text via olebole’s suggestion. Since I did not make these links, but they rather were the result of the install/make process I was just curious if someone knew where they were coming from and how to make a longterm fix.


olebole commented on 2017-05-04

IMO these files should just be symlinks to ../../unix/as/bytmov.c, ../../unix/hlib/d1mach.f, ../../unix/hlib/i1mach.f, and ../../unix/hlib/r1mach.f. The mistake here was to take absolute links instead of relative..

BTW, please check your messages before sending them. There is a “preview” button, and you have also some basic style elements (code, text, bold, etc.). Make it easy to read for others. Specifically this one looks really ugly. And there is no need to “@” mention us on any subject.


RobSteele49 commented on 2017-05-04

I’m curious if anyone know why most of the .c and .f files in /sys/osb reside there directly but the 4 files I indicated above are softlnks to the actually files. One possible fix is to copy the files from where the links are pointing to. But, that would mean there are multiple locations for the same file.

ls *.[cf]
abs.c achtbs.c achtib.c achtsu.c achtus.c bitfields.c bytmov.f f77upk.f ipak32.c r1mach.f zzeps2.f
achtbb.c achtbu.c achtiu.c achtub.c achtuu.c bswap2.c chrpak.c i1mach.f iscl32.c shift.c zzeps.f
achtbc.c achtbx.c achtlb.c achtuc.c achtux.c bswap2.f chrpak.f i32to64.c iscl64.c strpak.c
achtbd.c achtcb.c achtlu.c achtud.c achtxb.c bswap4.c chrupk.c i64to32.c iupk16.c strpak.f
achtbi.c achtcu.c achtrb.c achtui.c achtxu.c bswap4.f chrupk.f iand32.c iupk32.c strsum.c
achtbl.c achtdb.c achtru.c achtul.c aclrb.c bswap8.c d1mach.f imul32.c not.c strupk.c
achtbr.c achtdu.c achtsb.c achtur.c and.c bytmov.c f77pak.f ipak16.c or.c strupk.f


olebole commented on 2017-05-05

At least for bytemov.c, the resolution is system dependent, and therefore the symlink is a possible solution. This is fixed in #33 (see also the link above this message).

BTW, if you enclose a code section in two lines ` ``` `, you can use all characters, and the text is nicely formatted as code. This makes the text more readable.


RobSteele49 commented on 2017-05-05

As the change olebole made fixes this issue I’m going to close it. Thanks.


olebole commented on 2017-05-05

You don’t need to close; it will automatically be closed once my pull request is accepted. If Mike does not accept it, it will stay open then.


Closed on 2017-05-05