The collected works of vishnu - Page 11

It's probably incompatibilities between the version of X that the binary was linked to when it was compiled and the version of X that's on your workstation...

Nice to have options!

And now, in order to keep this thread continually off topic, I submit this lovely screencap of SGI's help->about popup from it's CDE dtterm, which is really just a CDE/SGI branded Motif xterm. Beautiful, isn't it?

I beleive the "X Windows Disaster" chapter of "The Unix Haters Manual" calls this font troglodite bold.

This is hilarious, like anything mozilla ever does on my system would be "critical"...

Or, more generally, the entire mozilla project is a critical programming error!

I've been trying to figure out how to download the North American Mesoscale model for years, with zero success, but this stuff looks way cooler...

After Tiananmen, I think they realized it was either start loosening up the latches or perish...

No I'm not that far yet I'm still lagging a bit behind your pace.

Very unusual architecture to this program, are you having the same problem as me with the Makefiles continually removing the dot-d files from the directories where you have to manually distribute them from Maxwell's tmp directory? Pretty annoying. Also, it's compiling everything so far into static libs which I assume will link into an eventual binary, but if it's compiling the individual source files into object files it's doing it very surreptitiously because I have yet to see one!

That does sound tempting, can you winnow out a spot for me in your hierarchy? You need a new minion...

Oh this just can not be good:

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."

Very nice Staffan! BTW do you have your trackball on the left because of right-hand mouse induced RSI? Because that's what happened to me. As a result now my left hand hurts too...

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

Ah a true lefty! I'm ambidextrous in the baseball sense; throw left bat right, but all the sociological research shows that true lefties score well above the average across the board in all categories. For example look at how well organized your computer workspace is, by comparison mine looks like it was organized by hand grenade...

Motif is, and probably always will be, the user interface toolkit of choice for the very highest end of the spectrum, for example Pro/ENGINEER uses it, Maya uses it, and then the brain dead morons who run the X foundation go and declare that the X Toolkit Intrinsics is deprecated. WTF!? Unix in particular and X in general have been wriggling on the stake of the mechanism-not-policy non-decision for 25 years and the end is nowhere in sight.

So anyway, rant aside (I could go on for hours) I've been using mwm on my Linux computers since Linux came out, mwm is not an exciting window manager so this is not an exciting screenshot but here it is:

Thinking back on it a little further (gosh, the memories!) my recollection is that Motif was first ported to Linux by either Metrolink or Xi Graphics, both companies subsequently cratered but Xi Graphics has risen from the ashes numerous times and is still looking to mine investorite and stay in business: http://www.xig.com/

I bought Motif on CD from Metrolink around 1995, prior to that I never used Linux because, let's be honest, TWM and Athena are horrible kludges that no one should ever have to use. Quite simply, the MIT group did an incredible job on Xlib and Xt and then just completely dropped the ball on the window manager and widget set. Personally, I think they were worn out and used mechanism-not-policy as an excuse to give up, at which point the commercial Unix industry got involved, and they obviously weren't going to give anything away, hence the toolkit wars and the OSF trying to milk Motif 1.1 for every possible nickel, despite the fact that it was so full of bugs as to be almost unusable, for which everyone in the OSF blamed every other member but themselves. No revisionist history there...

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."

What does mount say?

Okay, then how about prtvtoc /dev/root

And then, instead of fixing their toolkit they decided they could make it "compete with Motif" if they made it look 3D like the Motif widgets! Talk about compounding the idiocy...

No they really did release Motif as LGPL, in October 2012. Now if SGI would get off their dead asses and release Viewkit, we might actually be getting somewhere...

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...

I think all the attention deficit disorder kiddies are hacking on Gnome. It's the only explanation that makes sense...

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...

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...

Really/ My bad; too used to the sloppiness that gcc let's you get away with...

I have been moving this along in Linux, just not as conscientiously as on IRIX, but will keep slogging ahead until some sort of resolution is achieved...

That is friggin' incredible, only nine years ago! That's when my Octane2 was built, and you have to figure the Octane2 price list would be even higher since it was supposedly a genuine workstation, i.e. would keep working even if it got sucked into the vortex of an F5 tornado. As long as the AC cord didn't come unplugged...

It must have been a painful moment for SGI when they realized that that market no longer existed...

I dunno, sociologist who knew told me the funniest people in the world are Tibetan yak herders...

There are 313 c++ files in Maxwell, I just counted.

It boggles the mind that a project that was this far along when it got GPL'd was just ignored. Had to be the Motif curse. If it was GT freakin' K it'd probably be the centerpiece of Gnome by now...

FASH-KEE-NATING!

I've always wanted to (but never had a chance to) use X Designer. I do have a lot of experience using Rapid App and BX Pro which releive you of the responsibility for everything except the widget callbacks. Um, sort of obviously.

hamei, the other place is Integrated Computer Solutions, I wrote about the schism between them and The Open Group over the future of Motif in this post: http://forums.nekochan.net/viewtopic.php?f=15&t=16727601&p=7359004&hilit=helicopter+crash#p7359004

And yes you get the SGI "New and Enhanced Widgets" with IRIX, the files in the Sgm directory are demo programs designed to show you how they work.

Red fuming nitric acid dip?

Seriously though, hamei is right the search button will turn up a wide variety of threads on experiments our membership have conducted seriously oxidized sgi metalics...

From 2008 yes but little has changed, TOG still lists Motif 2.2.x as "experimental," motifzone.net (now motif.ics.com) is a morgue and all the development at ICS is on their QT and GTK gui builders. But as I keep repeating the two biggest commercial apps on Unix, Pro/Engineer and Maya, still use Motif and Xt, so, there it stands...

Nice! I'll package it in there if I ever get this bee-yotch compiled...

That's definitely too small to be useful as swap, by way of example my Blade 2500 came configured from Sun with 10 gig of swap.

There are 10 new widgets in Motif 2.2, a button box, color selector, column, data field, list, font selector, icon box, icon button, tab stack and tree, and tooltips are built into the Xm base class now.

With regard to the incompatibilities with earlier versions of Motif, they claim the most recent release fixed 76 bugs but there are almost 1600 bugs in their Bugzilla, only 133 of which show as resolved.

You can download the source code for 2.1.32 at the X Designer website: http://www.ist-inc.com/motif/download/motif_files/openmotif-2.1.32_IST.source.tar.gz Likewise they recommend against using Motif 2.2.x and pretty much manage rip it to shreds in this article: http://www.motifdeveloper.com/tips/Motif22Review.pdf

Despite all that my pal Dušan Peterc is doing some amazing things with the 2.3 widgets in his loom software, look through some of the explanations at his website and be amazed: http://www.arahne.si/ And like he says, his software doesn't try to fly helicopters so there's far less risk!

The Open Group is anything but...

Har...

I think it's paranoia; since Solaris has the authority to start killing user applications when RAM and swap are maxed out. Where I work, we load some truly gigantic models into apps like DYNA3D and even with 12 gig of RAM on my Blade 2500 it does occasionally thrash...

Presumably you don't have the cvd debugger that comes with Prodev Workshop?

Is that the version of cvd that comes with Prodev Workshop 2.9.1? Looks like they haven't updated the product information since MIPSPro 7.4 came out: http://techpubs.sgi.com/library/tpl/cgi-bin/summary.cgi?db=bks&docnumber=007-2582-006