X11-Fortran Problems

Why would you need X11 windows in any compilation phase?

Is this an open source project that some one else could look at? I have never heard of such a thing.

Has this code ever been compiled on a Mac before and/or recently? One of the strengths, or weaknesses, of Linux is that it will compile just about anything, regardless of quality. That code may not work on a 64-bit architecture or it may have some old Mac hacks that assume a PowerPC chip. It sounds like a one-of-a-kind, cobbled together mess. All bets are off.

aerohead wrote:

Yes, it is open source. It's licensed under GNU general public license.

Just so you know, open source and GPL are distinctly different. Open source means the project is distributed as source. GNU GPL means that you, the developer, is under some very significant restrictions and obligations.

It'd be fine for you to take a look at it. How should I transfer it to you?

Well, I don't have gfortran and I'm way too busy to install it right now. Is this project posted anywhere? I'm mainly trying to figure out how X11 is used in the build process. I was hoping the documentation might explain that.

I dug up a paragraph on what is called the original author calls the "graphics library." Here's what it says:

The graphics library employed by all plotting programs is Xplot11 (libPlt.a), which is aimed at driving X-terminals. It also allows a PostScript file plot.ps to be generated from the current visible screen plot at any time. Both color and black&white output is supported.

The idea of the build machine needing to construct some postscript file from a plot is just wrong. Generate the postscript files on the Linux machine and include the output in the project. Then eliminate the whole X11 part of the build process. Postscript files are resource files. There should be no need to construct those as part of a build script. It isn't a Mac vs Linux thing. The issue is constructing postscript files during build time. Something unusual like that needs a good justification.

aerohead wrote:

Once again, thanks for your quick response! Thanks for the clarification on the GPL vs. GNU.

Actually the issue is open source vs GPL. GNU and GPL are synonymous. But enough with that.

In reference to your final comment.... you think the problem doesn't lie with the build of libPltDP.a (the graphics plotting program) but rather in the MSES build itself?

I don't really know. That's the problem.

I am able to get the whole way through the MSES build without an error and am able to start up the program. Everything seems to work fine until I try to do a command which requires graphics.

You really have to clarify what, precisely, is the problem.

From what I understood, the build process includes a part where it opens an X11 windows, draws some stuff in it, and exports the contents of that window to a postscript file. I understood that what it was drawing was incorrect.

Now, you say it "works fine" until you try to do a command which requires graphics. What do you mean by "not working fine"? Do you get an error message? What does it say? Does it do nothing? What should it do? Are there any crash reports or Console.app log entries?

I really like to get things working on the Mac, but these academic projects really rub me the wrong way. The idea that people will push this junka and never update it in ten years really bothers me. Now, you want to run it on some machine that is ever so slightly different than its original build. I'm sure the author would blame the Mac. Why shouldn't he? It's not his problem. I'm doing his support for him, aren't I?

But I digress. I've had issues with academics lately.

What it sounds like now is that the software was just designed for the author's lab network at MIT in 1994 and has never been upgraded. It works fine on Linux because Linux was...designed in 1994 and has never been upgraded. In particular, it may be expecting a DISPLAY variable to be set. On the Mac, DISPLAY is set dynamically. Of course, I'm just guessing here. See about any error messages or log file entries. Dig into the script that it is exectuting and maybe add some debug statements.

OK. I get it now. That makes much more sense.

Alas, your job is much, much more difficult now. Obviously either the X11 or MSES portion was coded very poorly and has failed. Debugging it will be a tedious process to say the least. What you will probably have to do is isolate the various parts and test them individually. Once you find out where the failure lies, you can start to look for the cause.

One way you might be able to cheat is to rebuild the entire thing using Apple's new clang compiler. Not the FORTRAN parts, of course. Review the many thousands of warnings it is sure to emit. You may have to go into the Makefiles and remove the flags that hide those pesky things. You could do that with GCC too. It might be a good idea to start with full warnings on GCC. The only problem is that GCC's warnings are much harder to dechiper than those of clang. It will likely identify those places where the code is making invalid assumptions about endianness and the size and compatibility of data types. Then, it is just a matter of fixing the code.

Just a wild idea, but is there a scaling or zoom functon? Could you just be zoomed way in?

aerohead wrote:

Keith, in reference to the zooming... this code has been compiled on a Linux box successfully. I was trying to get it up and running on my Mac. I don't think it's a zoom/viewing issue, unfortunately. That would have solved a lot of problems if it did, though!

I'm with Keith. It is quite possible everything is being drawn normalized and something about that has gotten lost. Instead of drawing on a 1024 x 1024 canvas, you have a 1 x 1 canvas.

You might also try to view the postscript file with something, like photoshop maybe?