fitz |
09/26/2017 06:22PM (Read 5887 times)
|
|
|
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.
|
|
|
|
olebole |
09/26/2017 09:09PM
|
|
|
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...
|
|
|
|
fitz |
09/26/2017 09:17PM
|
|
|
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.
|
|
|
|
olebole |
09/26/2017 09:38PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzXGterm 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?
|
|
|
|
fitz |
09/26/2017 09:40PM
|
|
|
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.
|
|
|
|
olebole |
09/26/2017 09:59PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzSee 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.
|
|
|
|
fitz |
09/26/2017 10:16PM
|
|
|
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.
|
|
|
|
olebole |
09/26/2017 10:26PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzIf 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.
|
|
|
|
olebole |
09/27/2017 08:14AM
|
|
|
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?
|
|
|
|
fitz |
09/27/2017 09:36AM
|
|
|
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.
|
|
|
|
olebole |
09/27/2017 09:50AM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzIn 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?
|
|
|
|
fitz |
09/27/2017 09:55AM
|
|
|
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).
|
|
|
|
olebole |
09/27/2017 10:02AM
|
|
|
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.
|
|
|
|
fitz |
09/27/2017 10:08AM
|
|
|
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).
|
|
|
|
olebole |
09/27/2017 10:16AM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzIt'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.
|
|
|
|
fitz |
09/27/2017 02:00PM
|
|
|
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.
|
|
|
|
olebole |
09/27/2017 02:44PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzHuh? 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.
|
|
|
|
fitz |
09/27/2017 03:49PM
|
|
|
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.
|
|
|
|
evertonbt |
10/15/2017 11:59PM
|
|
|
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
|
|
|
|
fitz |
10/16/2017 03:10AM
|
|
|
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)
|
|
|
|
sastanford |
03/28/2018 11:58PM
|
|
|
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-
|
|
|
|
sastanford |
03/29/2018 04:07AM
|
|
|
Status: offline
Registered: 01/09/2008
Posts: 13
|
Found this solution:
setenv IMTDEV inet:5137
which solved the problem
|
|
|
|