fopen() call failure in OS X with OpenGL

D

daw

Registered
I've encounter a roadblock in porting OpenGL applications to Mac OS X. The problem centers around the "current working directory". Normal unix applications inherit the current working directory from the parent not the application, e.g. a call to fopen() looks to the directory from which an application was started, not from the directory in which the application happens to be stored. In unix apps ported to OS X that contains no calls to OpenGL, the unix convention is followed; however, if you link to Apples OpenGL.framework and GLUT.framework and include code to initialize the gl window, the current working directory switches from the parent to the application directory. This means that an fopen() call that is looking for a data file in the directory from which an application is launched cannot find the data file if it searches for it after any call to a glut library function (e.g. glutInit()) because that call changes the current working directory to the application directory.

For example, If you have a unix/openGL app in /usr/local/bin (not uncommon place to put your own special app's) and launch the application from your own home directory to analyze data in stored in your directory, Whether the application finds the data is dependent on when a call to fopen () is made. If the data file is opened before you uinitialize the gl window, the current working directory is the parent and the data file is found. If the data file is opened after you initialize the gl window, the current working directory has changed to "/usr/local/bin" in this example and your data file is MIA. Now that is just wrong!

I've reported this anomally to Apples developers bug reporting site over a month ago and have received NOTHING in return, not even the confirmation that this is a known bug. Has anyone found this same problem and is there a workaround till something is fixed in the Apple GLUT framework.

P.S. the answer is not "use the glut libraries in XFree86 4.2 and XDarwin". That does work and there is no switching of directories, but unaccelerated openGL is so unbareably slow as to make it unacceptable even as a temporary fix.

signed
Fed up with slow bug eaters at Apple!
 
I suppose for the moment you are just checking the current dir before and the call to the first glut function, then changing it back before you need the data file. Obviously not a valid long-term solution though, nor a particularly elegant one.
 
Scruffy,

I thought of that one, but it does not necessarily leave you with portable code. Apple is in the driver seat on this one. The change the unix standard should not occur and it needs their attention. The problem is getting some action. They either feel this is a low priority or do not want to address the problem, since I haven't heard one word after posting the bug with them.

There are functions for doing the call back which I dug out of there WEB site. One uses a CarbonStdCLib call "GetCurrentDirectoryUnixFormat(the_directory)" but I haven't gotten that to work primarily because I don't seem to have a mach 0 version of the library. Are there standard unix calls that return the current directory that I could use instead? At this point a Kluge is about all I can ask for.

A larger concern is why I can't get a response from Apple. I played by there rules, sent them the code, documented the problem, and even tracked it down to the glut library. Not one word of support. Bad form!

daw
 
getcwd(3) is in unistd.h, that should do it for you.

Yes, I agree it's bad form on Apple's part. But then, have a look at their excuse for a public source website - the last released version of Darwin is 1.4.1, while OS X 10.1.3 is version 5.3 (granted it should be 1.5.3; that's a typo introduced in 10.1, and has stuck around because we could never go back in version numbers, could we?)
 
Scruffy,

Thanks for your help. getcwb does return the current working directory, but the man page is just wrong. You can read what it says, but it does not return the size of the path string with "size_t size" as stated. I tried it as written and got unreliable results in different programs. e.g.
these lines of code

char mydir[128];
size_t length;

getcwd(mydir, length);
printf("pwd = %s, and length = %ld\n", mydir, length);

returns a lot of different things, sometimes kind of right, sometimes wrong e.g.
'pwd = /Users/daw/Library/Tracking/test, and length = 508'
in one program and
'pwd = , and length = 28'
in another run from the same directory! Odd, but true.

If you initialize length in the declaration, getcwd() returns the initailization value, e.g. length = 0 returns 0 and length = 128 returns 128.

If you set length to the size of the mydir array (i.e. 128), then mydir returns the correct path string all the time and the ruturn value of length is 128. This was found by trial and error after trying what the man pages describe.

I feel like Alice in wonderland.

So with this new found knowledge I implemented the chdir(mydir) call and now I can fopen my data files and display them in an OpenGL window... well, under certain circumstances.!?*&##%^

Here we go down another rabbit hole!

From the test directory above, my executables are stored in a bin directory that can be reached as follows:

>../bin/Setfilters imagefile.dat (note: imagefile.dat and image file)

This runs fine, I open the imagefile, mess with filters interactively and save a parameters file that holds my filtration kernels. I think I have finally beat the demon back, so I move a copy of the application to /usr/local/bin and set the ownership to root and chmod ugo+x . Pretty standard stuff right.

> which Setfilters
returns '/usr/local/bin/Setfilters' as expected and I try analyzing the image file again, this time with:

>Setfilters imagefile.dat
The OpenGL window launches, expected output is written to the terminal window and then a strange new line appeats on my terminal that says:
2002-03-07 11:28:05.575 Setfilters[319] Error 1011 in _sendFinishLaunchingNotification

The OpenGL window is frozen, can't be reached for comment, and the only way out is control-c.

This is not the unix I grew up on! Is that Steve Jobs over there in a top hat? Is that Bill Gates sucking on a huka. Where's the red queen? Off with their heads!
 
Note the length argument to getcwd() is a size_t not size_t *, so getcwd() doesn't return anything in it; it is simply how you tell getcwd() the size of the array you give it, so it doesn't overrun it.
 
blb,

Thanks, I think I understand that now. It doesn't explain the other oddities that violate standard unix conventions.

daw
 
Just ran in the same problem while writing a small shadowmapping tutorial with GLUT:

http://fabiensanglard.net/shadowmapping/index.php

Very sad that 7 years later, this issue is still here :( ! I guess it's not even worth it to complain to apple.

From within xcode, application was running fine (Debug or Release), but upon deployment and double click from Finder, no way to load the shaders.

With the informations found on this page, I used "getcwd" and found that when running the applicaton, "." = "/" while from xcode, "." is as expected.

I did not experiment the same issue with SDL application, but this is kindof completely defeating the purpose of GLUT !!
 
Last edited:
You must log in or register to reply here.
Back
Top