Welcome to iraf.net Thursday, March 28 2024 @ 04:58 PM GMT


 Forum Index > Help Desk > Systems New Topic Post Reply
 Can't get IRAF running on Mac OS X 10.11 because symlink will not be created (permissions issu...
   
andrej
 09/14/2015 07:49PM (Read 15828 times)  
+++--
Chatty

Status: offline


Registered: 08/21/2009
Posts: 57
Greetings.
I am in the process of having to reinstall IRAF since upgrading to 10.11 (currently at beta 6) broke my copy of IRAF.
I am in the process of troubleshooting why it's not working. I tried to reinstall IRAF following the directions located at:

http://www.iac.es/sieinvens/siepedia/pmwiki.php?n=HOWTOs.IrafMacOSX

since those were the only directions that I could understand (and worked for 10.10); the others confused me. But when I get to the end and type "cl" to launch IRAF, I receive the following error message:

os.zgtenv: cannot open `/usr/include/iraf.h'
task `cl' has no param file
Fatal startup error. CL dies.

I checked and there is no file called "iraf.h" located inside of /usr/include. It appears to have not been installed. There is no symlink for iraf.h. This seems to be the only error, since during the installation:

Creating symlink ... ln: /usr/include/iraf.h: Operation not permitted
[ FAIL ]


This appears to be a permissions issue. I tried changing the permissions of /usr/include using chmod to 777 and then reinstalling, but that still didn't work, as I got the same error message.

What do I do?

 
Profile Email
 Quote
fitz
 09/15/2015 10:46PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
The install script can be run either as a "personal" install where all needed links are put into your $HOME/.iraf directory, or as a "system" install where you need to run as root (or with 'sudo') to create links in system dirs like /usr/include. In the second case you would call the install script as

% sudo ./install --system

and then follow the prompts.

In either case, you can also just define a $iraf environment variable so the CL won't need to look for

 
Profile Email
 Quote
ncaon
 09/17/2015 03:43PM  
++---
Junior

Status: offline


Registered: 10/30/2005
Posts: 29
Hi Andrej,

I suspect that the problem with "Creating symlink ... ln: /usr/include/iraf.h: Operation not permitted" is related to the new so-called "Rootless" feature in Mac OS X 10.11, which does not allow users (even with sudo) to write into /usr/ and other system directories, as explained in http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really

You might try to disable the rootless feature, following the instructions in, for instance, http://tex.stackexchange.com/questions/249966/install-latex-on-mac-os-x-el-capitan-10-11

I do not know if there is any workaround on the IRAF side.

Cheers

Nicola




 
Profile Email
 Quote
fitz
 09/17/2015 04:17PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
The default installation of v2.16.1 does not require root permissions, i.e. all files are put into a $HOME/.iraf directory. For a single user machine this is normally adequate, otherwise each user of the machine will need to similarly run the install script. Defining

export iraf = /iraf/iraf/ # trailing '/' required
export tmp = /tmp/
export host = /iraf/iraf/unix/
export IRAFARCH = macintel
source $iraf/unix/hlib/irafuser.sh

will define a working environment that doesn't require the file.

Note I have installed 10.11 yet since it is still in beta, there may be other issues lurking as well.

 
Profile Email
 Quote
andrej
 09/21/2015 04:17PM  
+++--
Chatty

Status: offline


Registered: 08/21/2009
Posts: 57
I tried entering

export iraf = /iraf/iraf/

into the Terminal, and I received the following error message:

-bash: export: `=': not a valid identifier
-bash: export: `/iraf/iraf/': not a valid identifier

Can you be more clear on where I am supposed to enter

export iraf = /iraf/iraf/ # trailing '/' required
export tmp = /tmp/
export host = /iraf/iraf/unix/
export IRAFARCH = macintel
source $iraf/unix/hlib/irafuser.sh

?

 
Profile Email
 Quote
fitz
 09/21/2015 04:21PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
Don't put spaces before or after the '=' sign ......

 
Profile Email
 Quote
dcnicholls
 10/02/2015 08:59AM  
+----
Newbie

Status: offline


Registered: 10/02/2015
Posts: 3
Something that may be relevant (with El Capitan release version), xgterm that used to work in Mavericks and Yosemite and earlier is compiled with a hard coded links to, e.g., /usr/X11R6/lib/libXpm.4.dylib (three such links) and the X11R6 symbolic link in /usr to X11R6 is deleted when upgrading to El Capitan, so it doesn't work. Why the link to X11 in /usr is not deleted also is a mystery.

 
Profile Email
 Quote
dcnicholls
 10/02/2015 09:36AM  
+----
Newbie

Status: offline


Registered: 10/02/2015
Posts: 3
Also (the forum won't let me edit my previous reply), xgterm, ximtool etc are pre-compiled binaries, and have the illegal (in El Capitan) links embedded. So none of these will work under El Capitan no matter how it is compiled under El Capitan.

Does anyone know if the source code for these binaries is available?

 
Profile Email
 Quote
ncaon
 10/02/2015 11:08AM  
++---
Junior

Status: offline


Registered: 10/30/2005
Posts: 29
I have the same problem with xgterm after the OS upgrade to El Capitan.

The workaround I have found was to put the following bash function in my .bash_profile file:

PHP Formatted Code

xgterm () {
    (export DYLD_LIBRARY_PATH='/usr/X11/lib' ; \
     /iraf/iraf/vendor/x11iraf/bin.macintel/xgterm "$@")
}    
 


Then make sure that there are no other xgterm aliases or symlinks around, and the command xgterm calls the above function (I had to delete a symlink I had made in /usr/local/bin).

Hope it helps

Nicola

 
Profile Email
 Quote
dcnicholls
 10/02/2015 02:01PM  
+----
Newbie

Status: offline


Registered: 10/02/2015
Posts: 3
Right. It's working finally. I followed the install instructions on http://www.iac.es/sieinvens/siepedia/pmwiki.php?n=HOWTOs.IrafMacOSX, and got error messages pointing to files in illegal locations in El Capitan. The first was in xgterm, located in /iraf/iraf/vendor/x11iraf/bin.macintel/. It has about 6 links pointing to /usr/X11R6 After fixing the write permissions (sudo chmod...), I opened the xgterm executable in Hexfiend.app*, and changed all the '/usr/X11R6' to '///usr/X11'. The X11 link had been left after the El Cap upgrade. An alternative would be to change the link to '///opt/X11' which is where the X11 folder was located from before . The triple slashes are to pad the link length to the original link in case the compiled code looks at a particular file address.

The next step was to do a similar thing to the executable vocl.e, located in /iraf/iraf/bin.macintel/ Here I needed to change the link to iraf.h from '/usr/include/iraf.h' to '/opt/include/iraf.h' This then needed a 'sudo mkdir /opt/include/' and a symbolic link in the new directory to the actual file: 'sudo ln -sf /iraf/iraf/unic/hlib/libc/iraf.h'

After running mkiraf as per the instructions , running 'cl', IRAF runs nicely. I've only run it so far with stsdas, onesdspec, and splot so it is quite possible there are other hard coded links in vocl.e that need hacking.

Hope that helps.

* I used to use 0xED but it doesn't appear to work properly in El Cap.

 
Profile Email
 Quote
rmennick
 10/19/2015 12:43PM  
+----
Newbie

Status: offline


Registered: 10/19/2015
Posts: 1
Hello

I fix the problem installing smoothly UREKA and then using /Applications/Ureka/bin/xgterm (I installed Ureka in folder Applications).

Some notes:

1- UREKA is available at http://ssb.stsci.edu/ureka/
2- In MAC Terminal I used Preferences menu for opening /Applications/Ureka/bin/xgterm every time I open a normal terminal. Click "preferences" "profiles" "shell" and fill "execute command" window with "/Applications/Ureka/bin/xgterm & " also click in
"execute in a shell"

Hope it helps.
Regards



 
Profile Email
 Quote
fitz
 10/21/2015 04:09PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
I've just recently upgraded a machine to El Capitan but haven't seen any of the issues mentioned here. In particular, the xgterm/ximtool binaries don't hardcode the /usr/X11 path as far as I can tell, at least in the v2.16 binary version. It may be that the shared libs are still resolving to the old path left on your machine and that a reinstall of XQuartz would solve the issue.

I did find that the lack of a /usr/include revealed a bug in the code that was supposed to allow your $HOME/.iraf/iraf.h file to be used (in v2.16.1) wasn't working (the assumed path is actually $HOME/iraf/iraf.h). Defining a $iraf/$host/$tmp in your environment as in a previous post will work around not having a system /usr/include/iraf.h link.

 
Profile Email
 Quote
andrej
 10/26/2015 06:46PM  
+++--
Chatty

Status: offline


Registered: 08/21/2009
Posts: 57
Quote by: fitz

Don't put spaces before or after the '=' sign ......



Alright I did that, but then how come I have to do all the export commands every single time I want to start IRAF each time that I start up my computer?

 
Profile Email
 Quote
forgetting_iraf
 10/30/2015 12:31AM  
+----
Newbie

Status: offline


Registered: 10/30/2015
Posts: 1
Here is what worked for me. I ran 'sudo /iraf/iraf/install' without the --system option. When it asked me if I was running it as a superuser, I answered 'no', even if I had used the 'sudo' command. At that point the installation program decided to put the copy of iraf in my home directory, and I didn't run into the problems with /usr/include. I could then 'mkiraf' and run 'cl' without a problem.

 
Profile Email
 Quote
vsravani
 01/27/2016 03:44PM  
+----
Newbie

Status: offline


Registered: 10/01/2013
Posts: 10
This workaround suggested by the user "forgetting_iraf" worked like charm for me.

 
Profile Email
 Quote
keel
 03/29/2016 01:51PM  
+----
Newbie

Status: offline


Registered: 11/13/2006
Posts: 3
My desktop was just forcibly upgraded to 10.11 and I get a possibly related problem - starting xgterm always gives an error "can't open display". (For that matter, so does ximtool). The combination feels like a permissions problem. I installed from Ureka, in a subdirectory of my own home directory.


 
Profile Email Website
 Quote
fitz
 03/30/2016 06:17AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
A "cannot open display" means the task can't connect to the X server. Check that your DISPLAY variable isn't being reset to some machine name and is something like "/tmp/launch-31NZS8/org.macosforge.xquartz:0". You should also check that the XQuartz is being lanched by the Launch Agent, e.g. is it in the list shown by "launchctl list | grep xquartz" ?? Lastly, as I remember, the upgrade to El Cap also required an upgrade of XQuartz to solve various problems, try launch XQuartz manually or by opening an XTerm (if that works), then do a 'Check for Updates" from the task menu.

 
Profile Email
 Quote
keel
 03/30/2016 01:59PM  
+----
Newbie

Status: offline


Registered: 11/13/2006
Posts: 3
I may have posted too soon. I tried starting xgterm soon after installing XQuartz for the first time, and apparently needed a restart on something. I logged out of the whole system and redid all the setup, and now it works.

Relieved.

 
Profile Email Website
 Quote
kakirastern
 04/04/2017 07:15PM  
+----
Newbie

Status: offline


Registered: 03/30/2017
Posts: 2
Quote by: forgetting_iraf

Here is what worked for me. I ran 'sudo /iraf/iraf/install' without the --system option. When it asked me if I was running it as a superuser, I answered 'no', even if I had used the 'sudo' command. At that point the installation program decided to put the copy of iraf in my home directory, and I didn't run into the problems with /usr/include. I could then 'mkiraf' and run 'cl' without a problem.



I worked around this IRAF Mac-OS-specific legacy problem surrounding Apple Inc.'s so-called "rootless" feature, or more properly the System Integrity Protection (SIP), for post El Capitan or 10.11+ OS systems for Mac using user "forgetting_iraf"'s method with macOS Sierra running on my laptop as well. There is no need to use drastic means and resort to turn off SIP altogether. This is because as long as the package is unpacked at root while the IRAF is installed for only the current Mac user and not at the root level, the install script would not run into the missing "iraf.h" issue.

So if one follows the installation instructions on the IAC webpage at the URL: http://www.iac.es/sieinvens/siepedia/pmwiki.php?n=HOWTOs.IrafMacOSX , the only departure from the stated that needs to be effected comes in the second bullet point where the option "--system" should be intentionally omitted, so that the desired command now reads "sudo /iraf/iraf/install". Then when prompted whether the copy of IRAF if to be installed as the "root user", type "no" as opposed to the default setting.

 
Profile Email
 Quote
fitz
 04/04/2017 07:21PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
The 'sudo' is needed only for the '--system' option because the script then creates links in places like /usr/include or /usr/local that require root permission. Doing 'sudo /path/install' will run the install script for the root user, i.e. put things like the 'iraf.h' link in the root user's directory. Running just plain '/path/install' as yourself will install everything you need to run and compile under your account and avoid the SIP issue as well.

 
Profile Email
 Quote
   
Content generated in: 0.54 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