tbray@watsol.waterloo.edu (Tim Bray) (02/26/91)
I just finished building Motif 1.1 for an RS/6000, which required rebuilding Xt and R4 Xlib from scratch. Am having quite a bit of trouble getting the apps to run. To avoid static, I am running only the clients on the IBM against a known-to-be-OK server on a Sparc. Here's the symptom: Warning: Virtual bindings Initialize hasn't been called Memory fault (core dumped) So I checked with dbx, and sure'nuff, the Virtual Bindings Initialize, a.k.a. _XmVirtKeysInitialize, isn't getting called. Well, so I ran the same program under dbx on a machine where it works, and it turns out that _XmVirtKeys... is supposed to be called in the Vendor Shell initialization, right out of the Xt code. Here's a stack trace of how it gets there: _XmVirtKeysInitialize() VendorExtInitialize() <-from Xm/Vendor.c `Vendor`Initialize() <-from Xm/Vendor.c CallInitialize() <- All Xt from here up CallInitialize() CallInitialize() _XtCreate() _XtAppCreateShell() XtAppCreateShell() XtAppInitialize() XtInitialize() main() But on the IBM, it's not getting to VendorExtInitialize, because it's not getting to the Xm/Vendor.c's Initialize. However, it is getting the requisite 3 levels deep in Xt CallInitialize. I am starting to realize that I don't understand ShellWidgets and the Vendor code very well - apparently Xt just doesn't realize that it needs to call the Motif init code. Uh, how's it supposed to know? Is it a simple matter of -lXm being first on the command line & hence those Vendor.o symbols winning the race? If so, could the IBM linker be doing me a dirty? Thanks in advance for any rays of light... Tim Bray, University of Waterloo (tbray@watsol.waterloo.edu)
nazgul@alfalfa.com (Kee Hinckley) (02/27/91)
> it supposed to know? Is it a simple matter of -lXm being first on the > command line & hence those Vendor.o symbols winning the race? If so, could > the IBM linker be doing me a dirty? Could be. There are two versions of the routines, one in Xt and one in Xm. You definitely need the Xm one. This was a problem for me because I was making them Apollo global libraries and it didn't appreciate having two identically named entry points in the global name space. Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
dbrooks@osf.org (02/27/91)
Kee wrote: > Could be. There are two versions of the routines, one in Xt and one in Xm. > You definitely need the Xm one. This was a problem for me because I was > making them Apollo global libraries and it didn't appreciate having two > identically named entry points in the global name space. How did you solve it? If this is an absolute restriction, it must mean the Apollo architecture forbids one favorite solution to the patched Selection.c problem: tacking Selection.o onto the end of libXm.a. Correct? Or can the Apollo architecture stand having a static chunk of code text loaded from libXm.a (at ld time), and not clash with the same name in Xt (at runtime)? David Brooks Systems Engineering Open Software Foundation
nazgul@alfalfa.com (Kee Hinckley) (02/28/91)
> Kee wrote: > > Could be. There are two versions of the routines, one in Xt and one in Xm. > > You definitely need the Xm one. This was a problem for me because I was > > making them Apollo global libraries and it didn't appreciate having two > > identically named entry points in the global name space. > > How did you solve it? I through out the Xt version and replaced it with the Xm one. (Is there any reason this would screw up non-Motif apps?) > If this is an absolute restriction, it must mean the Apollo architecture forbids > one favorite solution to the patched Selection.c problem: tacking Selection.o > onto the end of libXm.a. Correct? Yes, but for more reasons than that. Apollo shared libraries are fully linked objects, they are not in archive format. > Or can the Apollo architecture stand having a static chunk of code text loaded > from libXm.a (at ld time), and not clash with the same name in Xt (at runtime)? I'm on weak ground here, since I basically know just enough about this stuff to get by - you'd be better off asking some of the ex-Apollo people who are working on OSF/1. They could tell you in a second. In general you can just do a replacement by "inlib"ing a piece of code before running your own. So you could simply force every app to link (either staticly or dynamicly) with the the fixed piece of code and you'd be golden. The catch is that the Intrinsics do everything indirectly. The catch is that the shared library has already decided that the Selection entry points are internal. So it's too late to tell them to use the new selection code - it will only affect your code. So I'm pretty sure there's no patch short of a whole new library. But as I say, go ping lwa@osf.org or someone and they'll tell you for sure. Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.