SGI: Development

Hmm, really? I've mostly used groff, and the one time I tried to use (La)TeX it had terrible table handling, lines all over the place.

I run into problems like that all the time... then I google something about my problem like table handling and copy and paste little bits of LaTeX mark up, or I reach for my books...

http://www.amazon.com/LaTeX-Document-Pr ... latex+book
http://www.amazon.com/LaTeX-Companions- ... x+book+set
http://www.amazon.com/s/ref=nb_sb_ss_c_ ... aps%2C6044

I fiddle with bits of mark up, I stumble a couple of times, then LaTeX does something awesome for me. Some times you have to fight with it a little and force it to layout things in a certain away otherwise it will put things as you say all over the place... I have tables with double lines, no lines, whatever I want, once I work out how, or copy and paste something from a tute or example that looks great. I borrowed the linux.sty file in my final year or university and hacked it a little and used it in an assignment. The lecturer was impressed I was handing in an assignment the day after handed out when there was two weeks to do it and there was a line of people outside his door complaining that it was "too difficult"... and the layout and presentation was just perfect. Just the way I wanted it. No fighting with WordPerfect, MS Word, WordStar or whatever was around at the time. It was computational linguistics and I was using a lot of symbols used in linguistics and maths.

You can do a lot of funky stuff with it... make text swirl in spirals and stuff. I like it and won't be giving it up anytime soon.


R.

Hidden even to find . -name \*.o from the top of the source tree? Wonders!


I'm seeing posts similar to this, but no solutions. Hate to think it might be intractable...

I'll give this a try (from techpubs )

"For compatibility with 7.4.3m, the older experimental
version of the C++ front-end based on EDG version 3.42 and
packaged as /usr/lib32/cmplrs/fecc_330 is still packaged and
will be invoked when -Zf,_330 (the flag was named the same
as it was in MIPSpro 7.4.3m and 7.4.2m) is added to the
compilation. This front-end is viewed as experimental,
unsupported and should be tried only when the other front-
ends are inadequate."

I decided to take a look at this and compile on x86.

This codebase is dated to say the least. To properly fix the .d issue, patch the makefile to change the CWD:



I'm still cleaning up headers to make this look like something from this century though.

EDIT: Discovered running make clean seems to reset the code base to defaults. How it does this I'm not sure, but my changes vanish after doing so.

Yes there's a whole lotta bad going on in those Makefiles...

Thank you, did try that but then found this :

Soooo ... have to hunt down Mrs Config.h.in now, I guess ...

That's a good trick to remember for the future tho.

Like vishnu said earlier in this thread... you need to do an 'autoreconf' at the top level before you call ./configure. If you don't, config.h.in simply doesn't exist. Also make sure you have GNU automake installed, else you wont have 'aclocal' which is needed for this creatio ex nihilo.

J.

I did ! i did ! Hones ... oh. Wait. I was in the wrong folder. I have like three of them, an original, one with corrected files, and a working one. Too confusing

this is the real error :

My guess is there's no makefile in there ... yet another small obstruction on our path to truth and righteous behavor

Time to reorganize and clean up this mess before I make it any worse ...

Have any of you guys gotten past mx_wp_editor.C yet? Because it's shortly after starting on that that I get this nightmare:

### Compiler Error during Scope Setup phase:
### value_field_nd 8916: not implemented
CC INTERNAL ERROR: /usr/lib32/cmplrs/fecc returned non-zero status 1

Going to try it with the other front end that techpubs claims is installed somewhere in the bowels of MIPSpro, will report back status at that point...

EDIT: Well according to techpubs I should have fecc_330 but I don't, I do have fecc_238 though so I tried that and, huzzah! It worked and I'm compiling again. I am now just as happy as though I were in my right mind. I thought computers were supposed to free us from this kind of drudgery not immerse us in it...

EDIT 2: When you get to geometry/geometry/gpline.C the compiler will fail on line 870, complaining that num_points needs to be a constant value. Looking through the code I see that num_points is a private integer member of two classes, each of which has three overloaded constructors, but by my cursory inspection it looks like the coders never set num_points to any value in any of the constructors, so what I did was change line 870 to bool inc[4096]; just to keep going. Once we get the beast running we can go back and fix it if it's a bug...

EDIT 3: So I think I've got the whole program built but the installation fails with Cannot find the Utopia Postscript Type 1 fontset which is required by Maxwell WP. Please install the four font files in /usr/lib/X11/fonts/Type1 . Having a look I see three Utopia fonts in that directory, Utopia-BoldItalic.pfa, Utopia-Italic.pfa, Utopia-Regular.pfa, presumably those are not the Postscript fonts Maxwell wants. Anyone know where I can get the right ones? Guess I'll go look. Oh, and I might also add that Jamie Zawinski is right about Postscript, it is "completely out of control."

Actually, I like PostScript. Or, well, no, can't say I like PostScript itself but unlike most cross-platform works-on-all-versions-of-Windows-newer-than-Vista ! garbage it actually is cross-platform and it does work with anything and if you insist on a PostScript printer, the thing just works anywhere with a simple PPD file.

So Jamie could be correct that PostScript is awful but the damned thing does what it says, entirely un like that abortion Portable Document Format that is about as portable as the Empire State Building.

All I can say is, I hope the next bomb is set in the corner office, top floor of whatever building Adobe uses to run their villainous enterprise.



Back to le sujet at hand ... made a tardist of all the changes I had to do. Probably missed documenting a few. Many were simple, such as renaming < configure.in > to < configure.ac >. That didn't actually fix anything but at least it's one fewer warning.

The configure.ac script explicitly defines a section to chmod two necessary build scripts to 755. For some reason, when you run configure it does exactly the opposite and chmods those files back to 644. Very helpful. At this moment you will still have to fix that manually. Shouldn't be a big deal to fix but for now ... hope I mentioned which ones in the revised README

This was my environent, unlike vishnu I had no problems finding Motif



Some things I did that are most likely not so good but at least the compiler will get past the errors were :

Changed ranlib to touch in two places. The make process didn't want to proceed by just nulling out ranlib.

Changed < ar -s > to < ar -ru > in a couple places. MIPSPro insisted on

so < ar -ru > seems to be the closest. That's probably wrong.

If I ran autoreconfig I got a peculiar error regarding Motif. If I ran autoconfig and autoheader per the INSTALL directions, I did not. No idea which way is better but one gave fewer errors so I went with the fine manual

{ tarfile deleted due to unexpected behavior }

I've got to tell you this homegrown build system that they made is fucked uuuuuup, I finally got to the point where make all goes all the way through the source tree, and never invokes the compiler, so I figure it's done, right? Wrong! It's supposed to create an exe directory and put the maxwell executable in there, but nothing. All I've got for all this work (well okay, maybe typing `make` 87 million times isn't work) are these static libs that it put in the lib directory:

-rw-r--r-- 1 vishnu user 41236 May 4 20:48 libmx_dgui.a
-rw-r--r-- 1 vishnu user 547252 May 4 17:40 libmx_dgedit.a
-rw-r--r-- 1 vishnu user 273876 May 4 17:36 libmx_geomstyle.a
-rw-r--r-- 1 vishnu user 252388 May 4 17:35 libmx_raster.a
-rw-r--r-- 1 vishnu user 148548 May 4 17:30 libmx_help.a
-rw-r--r-- 1 vishnu user 377924 May 4 17:29 libmx_geometry.a
-rw-r--r-- 1 vishnu user 530068 May 4 14:44 libmx_rtf.a
-rw-r--r-- 1 vishnu user 1247924 May 4 14:41 libmx_ui.a
-rw-r--r-- 1 vishnu user 1601028 May 4 14:25 libmx_edit.a
-rw-r--r-- 1 vishnu user 3028964 May 2 20:16 libmx_document.a
-rw-r--r-- 1 vishnu user 1270292 May 1 20:44 libmx_view.a
-rw-r--r-- 1 vishnu user 245748 Apr 29 01:52 libmx_collection.a
-rw-r--r-- 1 vishnu user 288676 Apr 29 01:39 libmx_db.a
-rw-r--r-- 1 vishnu user 220532 Apr 28 17:45 libmx_shared.a

Hmmmm, methinks, I'll try make maxwell but that doesn't work either, at least, not from the top of the source tree:

make: *** No rule to make target `maxwell'. Stop.

So then I grepped around the source tree for a while looking for the file that's got int main , thinking that's probably where the Makefile that has maxwell as a target will be, but I haven't been able to find it yet. And, as I said before, it's utterly mystifying to me how it does all this compiling without a single object file ever becoming visible to the naked eye.

So anyway, hamei I'll grab your tarball hopefully I'll have better luck with it than the disaster that just happened in my sandbox...

EDIT: hamei, WTF? You hacked the build system to change one of the static lib target names to shit ??? I agree this process has been enormously tiresome but that is not helpful...

Oh, right. Oops. Sorry, forgot about that We may want to change that back. Not that it seems to make any difference ...

Other than that, Mrs Lincoln, how did the rest of it go ?

edit: Oh wait. It looks like "make clean" doesn't. That's nice. There's all kinds of earlier junk in there. I will go ditch it now and make a better one ... sorry. What a joy.

Maybe can help with this part anyhow - look in sourceroot/build for < mxinstall > . About halfway through :


Butcher to your heart's content

Okay le, hope this is better ... I think I (manually) cleaned out all the old junk.


For me, autoconf then autohead then ./configure --prefix=/usr/nekoware, all goes well.

Then go into /build and chmod 755 both mxinstall and movedep

Then gmake

It *should* compile clean up until you get to /dgui/dialogue

At that point the Makefile is empty. Configure says it built the makefile and it did, but there's nothing in that directory and no instructions in the makefile. A correct sample (for the toolbar) :


What's in the dialogue Makefile :


And no C files in that directory and no C files in that directory in the older pre-autoconf release either, where all the other subsystems do have source files and headers and such. So I am at a loss. Next thing to try will be to remove that subsystem from the make process but that doesn't really sound right.

How did you get past there ?


Is your < /build/mxinstall > executable ? I also noticed some mention of "make exe" when I was looking a reason for why it didn't create the dialogs makefile ... it may need "gmake exe" to finally make the binary ?

this is not exactly what you'd call foolproof

btw ... if you need a confidence-builder, I got the same libraries. So at least we are both going in the same direction ... a couple more (I hope helpful) things I noticed : the mxinstall script does work but it doesn't like the font names that Irix uses. If you change the font names to Utopia-Regular, Utopia-Bold etc etc then it will create the fonts directory and create links. It also creates a link to ispell whether you have it or not

I also noticed that the script looks in your sourceroot / exe and sourceroot / bin directories for a < maxwell > (I assume) executable. Judging by configuration's prior inability to create directories, perhaps it would be worthwhile to make those directories manually before hitting gmake ?

I also have object files all over the place but not sure where they came from. Last time I looked there weren't any ? Is that a good sign, do you s'pose ? Are we going to meet the Red Queen soon ?

Sorry for the delayed response - I have it running under IRIX 6.5

I think the very first error you encounter entails having to chmod 755 build/movedep, and then the last is having to chmod 755 build/mxinstall. And I did comment out the Utopia fonts section of mxinstall, which is when I realized that it wasn't going to perform the hoped-for magic of compiling all the static libs into a binary named maxwell. And I too noticed that mxinstall complains about not finding lpr and ispell, which obviously are minor complaints compared to no freakin' executable.

And in the directory dgui/dialogue I have a Makefile that has the same sourceless content as the Makefile in your tarball, my compile never stopped in there, yours did?

But yeah after I made that last change to line 870 in gpline.C doing `make all` (on my system make is a symlink to gmake) goes through the entire source tree and exits without ever invoking the compiler, so obviously I assumed it was done, but it never creates the maxwell binary.

And I did find the C file with the call to main(), it's in the edit/app subdirectory, maxwell.C logically enough.

Oh and I see now why there's never an object file, as soon as one gets created it's contents are dumped into one of the static library files in the lib directory at the top of the source tree and then the Makefile deletes the object file. Gotta say I'm not sure what the thinking behind that morphology is, but whatever...


I guess that speaks volumes to SGI's ability to keep backward compatibility alive in their shared objects...

Ja, for me make stops and says, "nothing to see here, we're done, no more work today, let's go have a beer !" and that's all she wrote.


Well, you never can tell ... maybe it does it in secret. Given the way the rest of it works, anything is possible

I did notice that there were supposed to be binaries in either /bin or /exe, tho. Or maybe both. And given all the other missing directories, since yours doesn't get lazy at /dgui, maybe try manually creating those directories ? It might be secretly making the executables but can't put them anywhere ?

What I find strange is, this thing has been on Sourceforge for what, fifteen years ? And no one noticed the missing source code files ? They aren't in any of the versions of the source which I have.

If I hadn't seen screenshots I would have a hard time believing this thing ever existed

Yeah I did create those directories, didn't help, but I did do something that I think is very enlightening, I wrote a shell script that greps through every makefile in the source tree looking for one that has "maxwell" as a target, and there isn't one. Let that sink in for a minute. There. Isn't. One.

For grins I've attached the shell script, if you run it from the top of the maxwell source tree it will print every line in all 83 makefiles that have the word maxwell in them, and just from a cursory inspection you can see that the word is never used as a make target. W, as they say, T.F. Anyway, I had to gzip the shell script because phpBB in its infinite wisdom won't let me upload a file with sh as the file extension, because, you know, only L33T HaX0r dudes would do something like that.

So then I got the bright idea of trying to compile all the static libs into a binary myself, so I cd'd into the lib directory and did CC -L/usr/lib32 -lXm -lXt -lX11 *.a -o maxwell - which failed with unresolved text symbol "main," so then I had the clever idea to compile maxwell.C into an object file, because I knew from an earlier search that that's the file that has the must-have call to main(), so I did that, and copied the file to the lib directory and did CC -L/usr/lib32 -lXm -lXt -lX11 *.a maxwell.o -o maxwell - and that failed with this nightmare:

ld32: WARNING 84 : /usr/lib32/libXm.so is not used for resolving any symbol.
ld32: WARNING 84 : libmx_collection.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_db.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_dgedit.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_dgui.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_document.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_edit.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_geometry.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_geomstyle.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_help.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_raster.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_rtf.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_shared.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_ui.a is not used for resolving any symbol.
ld32: WARNING 84 : libmx_view.a is not used for resolving any symbol.
ld32: ERROR 33 : Unresolved text symbol "XGetErrorText" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_printf_warning(const char* ...)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_app::stop(int&)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_app::unlock(void)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XOpenDisplay" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XCloseDisplay" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XtDisplay" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XtDatabase" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XrmCombineFileDatabase" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_config::mx_config(int&,char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_error_clear_func(int&,int,char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_copy_file(int&,char*,char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_trace_func(int,char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_error_check_func(int&,int,char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_db_client_open_wp_doc__GRiPcbPPcT4Rl21mx_file_create_type_t" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_is_file_type(const char*,mx_file_type_t)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_app::is_doc_open(char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_app::new_wp_editor(int&,mx_wp_document*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_ui_object::set_busy(_WidgetRec*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_config::get_default_string(int&,char*,char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_db_client_open_temporary_wp_doc(int&,char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_ui_object::clear_busy(_WidgetRec*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XtAppSetWarningHandler" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XtAppSetErrorHandler" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_version::get_default_maxhome(void) const" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_string_copy(const char*)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_db_client_login(int&)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XtVaAppInitialize" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XSetErrorHandler" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_error_stack::init_exit_proc(void (*)(void))" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_app::init(void)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_font::mx_font(void)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_font::get_x_fontname(int&,float,unsigned long,unsigned long)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_font::~mx_font(void)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XLoadQueryFont" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "XFreeFont" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_app::run(int&)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol "mx_error_stack::print(void)" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved data symbol "maxwell_version" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: ERROR 33 : Unresolved data symbol "global_error_trace" -- 1st referenced by maxwell.o.
Use linker option -v to see when and which objects, archives and dsos are loaded.
ld32: INFO 152: Output file removed because of error.

Why is it complaining about Xt and X function calls when I explicitly told it to link against those libraries? Fuck. This. Shit. It is obviously the will of Allah that I throw my Octane out the window. I submit to the will of Allah...

Since I don't have a Linux box and you do ...... your mission, should you choose to accept it ...

What do you think about trying this devil out in Linux ? It shouldn't matter, it should do the exact same thing but in theory this thing compiles on Linux. It's been on Sourceforge for fifteen years, fer gosh sakes. Someone, somewhere should have noticed that it never tries to create an exacutable ?

Yes, I think attempting a compile on linux is a good strategy. I had a quick play but I hit a compile problem on the first source file it came to before implementing a fix so I think it's going to be an uphill struggle even on linux.

Oh, and I think there are targets for executables in the build system but they depend on tags created in the exe directory, so I think you would end up with an exe.

I found this article http://linuxgazette.net/issue27/ayers2.html which provides some background in case anyone is interested. The fact that it was an early release that was abandoned (and then the source code was released at some point after that) would suggest that there probably wasn't the rigour imposed by external scrutiny which brings most open source projects up to scratch.