Welcome to iraf.net Thursday, March 28 2024 @ 10:39 AM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 IRAF and OSX High Sierra
   
fitz
 09/26/2017 06:22PM (Read 5867 times)  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040

The recent release of OSX High Sierra has turned up no new problems for IRAF v2.16.1. As with previous releases of El Capitan and Sierra, there may be some initial problems with the X11IRAF tools (XGterm and XImtool) due to changes in the XQuartz placement of files. These can be worked around by defining an environment variable in your .cshrc/.login file (C-shell) or .bashrc/.profile (Bash users):

export DYLD_LIBRARY_PATH /usr/X11/lib (Bash)
setenv DYLD_LIBRARY_PATH /usr/X11/lib (C-shell)

This OS also keeps the "System Integrity Protection (SIP)" feature that may prevent a system-wide IRAF installation by restricting writes to system directories such as /usr. This can be worked around by either using the default personal installation option when running the install script, or you can choose to disable SIP entirely for your machine (see e.g. http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/ for details).

High Sierra will be the last version of OSX to fully support 32-bit applications, meaning future releases will no longer run the 'macosx' architecture binaries, 32-bit-only external packages such as STSDAS/TABLES, and the X11IRAF tools. Users should begin transitioning to the 64-bit 'macintel' architecture if they have not already done so.

 
Profile Email
 Quote
olebole
 09/26/2017 09:09PM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz


High Sierra will be the last version of OSX to fully support 32-bit applications, meaning future releases will no longer run the 'macosx' architecture binaries, 32-bit-only external packages such as STSDAS/TABLES, and the X11IRAF tools. Users should begin transitioning to the 64-bit 'macintel' architecture if they have not already done so.


Since xgterm is the mostly wanted tool from X11IRAF and it seems that it may compile with 64 bit as well: Wouldn't it make sense to separately distribute a 64-bit xgterm? I asked this already on github, but you seem to ignored github since quite a while...

 
Profile Email Website
 Quote
fitz
 09/26/2017 09:17PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
XGterm just happens to compile on some systems, and appears to work most of the time on some systems, but that is a far cry from having it be a fully supported 64-bit application that we distribute. There are no plans to port XGterm to 64-bit, users are free to compile it if they choose but are on their own in doing so.

 
Profile Email
 Quote
olebole
 09/26/2017 09:38PM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz

XGterm just happens to compile on some systems, and appears to work most of the time on some systems, but that is a far cry from having it be a fully supported 64-bit application that we distribute. There are no plans to port XGterm to 64-bit, users are free to compile it if they choose but are on their own in doing so.


Are there any problems known with the 64-bit xgterm?

 
Profile Email Website
 Quote
fitz
 09/26/2017 09:40PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
See the original post about the segfault that happens which surprised us both by pointing out xgterm even ran under 64-bit ..... I've also seen it fail at random times myself under CentOS 6.9.

 
Profile Email
 Quote
olebole
 09/26/2017 09:59PM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz

See the original post about the segfault that happens which surprised us both by pointing out xgterm even ran under 64-bit ..... I've also seen it fail at random times myself under CentOS 6.9.


I just trusted the "X11IRAF does not work on 64 bit" without even trying to compile xgterm separately.

The nice thing about having this in a (central) git repository is that others can contribute their problems (hopefully reproducible) and patches, even if it is not a "fully supported application". Come on, we just made IRAF compiling and working again on modern platforms, why shouldn't that work out for xgterm?

And, IRAF is anyway not in a state where it is "fully supported": there are several bugs (see the github repository); even serious security riscs, which have no response from you.

 
Profile Email Website
 Quote
fitz
 09/26/2017 10:16PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
If you would like to fork the project and support 64-bit then please do so, I would eagerly be one of the first users even though I wouldn't have time to contribute.

 
Profile Email
 Quote
olebole
 09/26/2017 10:26PM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz

If you would like to fork the project and support 64-bit then please do so, I would eagerly be one of the first users even though I wouldn't have time to contribute.



Sure: But step by step. Let's first fix IRAF itself (which means: resolve the problems there) and then take the next step. Without a usable IRAF on modern systems, it does not make sense to get an xgterm working. And it is not usable: a simple SPP build fails on recent Debian (and probably Ubuntu) systems. Security problems on top of that.

And for IRAF itself, I delivered quite a number of well-documented and tested patches which await your racceptance since several months.

 
Profile Email Website
 Quote
olebole
 09/27/2017 08:14AM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz


This OS also keeps the "System Integrity Protection (SIP)" feature that may prevent a system-wide IRAF installation by restricting writes to system directories such as /usr. This can be worked around by either using the default personal installation option when running the install script, or you can choose to disable SIP entirely for your machine (see e.g. http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/ for details).


IRAF does not write to system directories (/System, /bin, /usr, and /sbin), right? What is the specific problem here?

 
Profile Email Website
 Quote
fitz
 09/27/2017 09:36AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
In a "system install" (i.e. the install script run as "install --system" as 'root' or with 'sudo'), a symlink is made to /usr/include, binaries may be put to /usr/local or /usr/bin depending on paths set by the user. The default install script behavior is to do a "personal install" under a user's account so no root permission is required, but shared servers sometimes still use the system option.

 
Profile Email
 Quote
olebole
 09/27/2017 09:50AM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz

In a "system install" (i.e. the install script run as "install --system" as 'root' or with 'sudo'), a symlink is made to /usr/include, binaries may be put to /usr/local or /usr/bin depending on paths set by the user. The default install script behavior is to do a "personal install" under a user's account so no root permission is required, but shared servers sometimes still use the system option.


Why isn't the usual path for a system install on Mac /Applications/iraf (which would be the default for MacOS)?
I think this should be changed in the git repository. Would you agree?

 
Profile Email Website
 Quote
fitz
 09/27/2017 09:55AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
No I wouldn't agree, the user can choose to use that path if they wish but just because it's in /Applications doesn't mean it will behave the same as other OSX applications (e.g. when selected by Finder, you can't do an "open -a iraf", etc).

 
Profile Email
 Quote
olebole
 09/27/2017 10:02AM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
But just asking to lower the security level is a quite bad idea, especially for shared servers.

 
Profile Email Website
 Quote
fitz
 09/27/2017 10:08AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
It's the user's option, not our recommendation, that the SIP be disabled and it's still possible to do a system install using only user accounts by setting appropriate environment variables ($iraf, $path, etc).

 
Profile Email
 Quote
olebole
 09/27/2017 10:16AM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz

It's the user's option, not our recommendation, that the SIP be disabled and it's still possible to do a system install using only user accounts by setting appropriate environment variables ($iraf, $path, etc).


But as far as I understand you, for shared servers it is not possible to set those variables, right? They are then determined from reading /usr/include/iraf.h.

 
Profile Email Website
 Quote
fitz
 09/27/2017 02:00PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
Huh? Any user on the machine could set a $iraf if they wanted to, it just wouldn't be possible for the install script to do it automatically.

 
Profile Email
 Quote
olebole
 09/27/2017 02:44PM  
++++-
Regular Member

Status: offline


Registered: 05/01/2014
Posts: 103
Quote by: fitz

Huh? Any user on the machine could set a $iraf if they wanted to, it just wouldn't be possible for the install script to do it automatically.


OK, so I probably just misinterpreted this statement where you wrote:
Basically the irafks.e process that is started remotely needs to know where iraf is installed to initialize the process and uses to get the IRAF/HOST/TMP paths.


But why not have it in /etc/defaults? This is the usual place for system wide application settings in Linux, but also for Unix programs on MacOS. This directory is also not protected by SIP, and therefore a better place than /usr/include/iraf.h, and one would avoid abusing a include file for runtime configuration issues.

If you ask who is going to implement this: I would volunteer. But you should at some point start to process the already existing pull requests.

 
Profile Email Website
 Quote
fitz
 09/27/2017 03:49PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
If you want to implement it, feel free. In practical terms, though, it "fixes" a problem that doesn't exist given the default personal installation, the fact that most Macs are personal machines not shared servers, and the availability of workarounds where those few shared machines might actually exist.

 
Profile Email
 Quote
evertonbt
 10/15/2017 11:59PM  
+----
Newbie

Status: offline


Registered: 10/09/2017
Posts: 4
Quote by: fitz


The recent release of OSX High Sierra has turned up no new problems for IRAF v2.16.1. As with previous releases of El Capitan and Sierra, there may be some initial problems with the X11IRAF tools (XGterm and XImtool) due to changes in the XQuartz placement of files. These can be worked around by defining an environment variable in your .cshrc/.login file (C-shell) or .bashrc/.profile (Bash users):

export DYLD_LIBRARY_PATH /usr/X11/lib (Bash)
setenv DYLD_LIBRARY_PATH /usr/X11/lib (C-shell)

This OS also keeps the "System Integrity Protection (SIP)" feature that may prevent a system-wide IRAF installation by restricting writes to system directories such as /usr. This can be worked around by either using the default personal installation option when running the install script, or you can choose to disable SIP entirely for your machine (see e.g. http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/ for details).

High Sierra will be the last version of OSX to fully support 32-bit applications, meaning future releases will no longer run the 'macosx' architecture binaries, 32-bit-only external packages such as STSDAS/TABLES, and the X11IRAF tools. Users should begin transitioning to the 64-bit 'macintel' architecture if they have not already done so.




Hi there,

I`m not been able to install the sternal packages, every time I type in terminal the command ./configure in ../extern I get this:

PHP Formatted Code
Initializing repository data ....
Cannot download repository manifest file, quitting.
Creating system makefile ....
Setup Complete.
cat: .repo_pkgs: No such file or directory


    To install packages, use 'ls' to list the currently available
    packages from the IRAF repository.  For each package you wish
    to install, use the command:

      make <pkg>

    The package will be loaded dynamically the next time you start
    the CL session.

    Use the commmands:

      make update       # to update pkgs to the latest repository version
      make check        # to list available updates
      make clean        # to delete installed all packages
      make init         # restore to pre-configure state
      make <pkg>        # to force a re-install of named <pkg>
 


It seems that it cannot connect to repositories.
Do you have any idea about? Are you experiencing this?
I started a post in other place, but no one answered yet.
Its happening in high Sierra, cause it works on Sierra and previews OS (I did everything the same).
I'm using the latest Iraf.

Thanks.

Everton

 
Profile Email
 Quote
fitz
 10/16/2017 03:10AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040

So it turns out that the DYLD_LIBRARY_PATH recommendation is needed for the correct libraries to resolve for X11IRAF, but XQuartz provides it's own libPng.dylib that conflicts with the one in the system library, the script that does the downloads using the x_system,e binary then fails with the error you report.

If you added the DYLD_LIBRARY_PATH to one of your startup files the quick fix is to simply unset it from your environment before you run the 'configure' command.

Also, instead of defining the DYLD_LIBRARY_PATH in startup files, you can apply it only to the X11IRAF tools using an alias such as:

alias xg="(export DYLD_LIBRARY_PATH=/usr/X11/lib && xgterm)" # (for Bash users)
or
alias xg "(setenv DYLD_LIBRARY_PATH /usr/X11/lib ; xgterm)" # (for C-shell users)

 
Profile Email
 Quote
sastanford
 03/28/2018 11:58PM  
+----
Newbie

Status: offline


Registered: 01/09/2008
Posts: 13
Recently upgraded to High Sierra, now when trying to display from IRAF to ds9 I get the old cannot open device (node! imtool, 8192, 8192). I believe I have the current X11 (2.7.11) and current DS9 (7.6 b8). Tried the suggestion below (setenv DYLD_LIBRARY_PATH /usr/X11/lib ) but no change.

thanks-

 
Profile Email
 Quote
sastanford
 03/29/2018 04:07AM  
+----
Newbie

Status: offline


Registered: 01/09/2008
Posts: 13
Found this solution:

setenv IMTDEV inet:5137

which solved the problem

 
Profile Email
 Quote
   
Content generated in: 0.70 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login