umh@vax5.cit.cornell.edu (03/31/91)
Has anyone been able to get this to work? I have code that I wrote on Sparcs that utilizes Xt, Motif and is written in C++. I tried to port it to the RS/6000. The first problem was that the X you get given is X11R3, but our system manager has the X11R4 headers and some library files tucked away (and not the default headers and libraries because he says they are still buggy.) Because I'm using C++ I had to use these R4 headers and once they'd been massaged my code compiled fine. However when I tried to run it, it said that libXm.a[shr.o] could not been found. So I imagined this is a problem with runtime libraries. I look in /usr/lib and libXm.a is there so I don't know why it can't find it, but anyway I set my environment variable LIBPATH to /usr/lib and this works in that it finds libXm.a and I get a new error message about libXt.a being of incorrect XCOFF format. As far as I can tell XCOFF refers to how the object modules in a library talk to each other. So does this error mean my X11R4 compiled program wants the X11R4 version of libXt.a and lands up getting the X11R3 one from /usr/lib? Does it mean it wants the X11R3 one from /usr/lib and lands up getting one from /usr/local/deeple_burried_down/beta/X11R4/lib where it was also trying to look for libXm.a? Does it mean that the X11R4 libXt.a is corrupted and should be recompiled? Is there anway I can avoid this nonsense and just compile the thing not to use shared libraries, like the -Bstatic flag on Suns? Info spoke about a thing called a binder which ld accesses. In a fit of optimism I hoped this might be the runtime linker, and so I set the -nobind flag for the loader, but this produced a whole bunch of compiler speak which made no sense, and resulted in no executable so I gave up. IBM have asked us *please* to write motif software in C++ for them? Are they asking the impossible? Maynard Handley Cornell University maynard@helios.tn.cornell.edu
marc@ibmpa.awdpa.ibm.com (Marc Pawliger) (04/02/91)
[... talk of executing a program and getting 'cannot load libXXX.a, incorrect format' deleted ...] What has probably happened is that you have linked with a shared library that is not in the 'standard' place i.e. /lib or /usr/lib. When you go to run the program, the loaded can't find the library and bails out. Unfortunately it sometimes reports the wrong library as the one it couldn't find or that was in the 'wrong format'. The solution is to use the -L switch when compiling. This basically adds another directory to the path searched for shared libraries. So if the R4 libraries were in /usr/local/lib, you would add "-L/usr/local/lib -lX11" to use /usr/local/lib/libX11.a instead of /usr/lib/libX11.a. To see if this will work, you could also set LIBPATH to /usr/local/lib:/lib:/usr/lib and try re-running the program. If that works, then recompiling should help. +--Marc Pawliger----IBM Advanced Workstations Division----Palo Alto, CA---+ | Internet: marc@ibminet.awdpa.ibm.com VNET: MARCP at AUSVM6 | | UUCP: uunet!ibminet.awdpa.ibm.com!marc Phone: (415) 855-3493 | +-----IBMinet: marc@ibmpa.awdpa.ibm.com----------IBM T/L: 465-3493------+ These are my opinions, not IBM's etc etc etc
wross@caen.engin.umich.edu (Wendy Ross) (04/02/91)
In article <1991Apr1.100448@ibmpa.awdpa.ibm.com> marc@ibmpa.awdpa.ibm.com (Marc Pawliger) writes: >[... talk of executing a program and getting 'cannot load libXXX.a, incorrect >format' deleted ...] > >What has probably happened is that you have linked with a shared library that >is not in the 'standard' place i.e. /lib or /usr/lib. When you go to run the >program, the loaded can't find the library and bails out. Unfortunately it >sometimes reports the wrong library as the one it couldn't find or that was >in the 'wrong format'. > >The solution is to use the -L switch when compiling. This basically adds >another directory to the path searched for shared libraries. So if the R4 >libraries were in /usr/local/lib, you would add "-L/usr/local/lib -lX11" to >use /usr/local/lib/libX11.a instead of /usr/lib/libX11.a. > >To see if this will work, you could also set LIBPATH to >/usr/local/lib:/lib:/usr/lib and try re-running the program. If that works, >then recompiling should help. > >+--Marc Pawliger----IBM Advanced Workstations Division----Palo Alto, CA---+ >| Internet: marc@ibminet.awdpa.ibm.com VNET: MARCP at AUSVM6 | >| UUCP: uunet!ibminet.awdpa.ibm.com!marc Phone: (415) 855-3493 | >+-----IBMinet: marc@ibmpa.awdpa.ibm.com----------IBM T/L: 465-3493------+ > >These are my opinions, not IBM's etc etc etc I have a question. We also are compiling X11R4 with the suggested patches. We did compile it with the -L option so that the clients will use our X11R4 shared libraries instead of /usr/lib libraries. Everything works just fine if the clients (ie xterm) is not suid. xterm runs without problems, and finds the right library. However, as soon as we make xterm suid root, it bombs out with the XCOFF error, saying something about /usr/lib/libXt.a. Is there some reason that suid programs only look in /usr/lib? Does anyone have any other suggestions? Wendy Ross wross@caen.engin.umich.edu Computer Aided Engineering Network College of Engineering University of Michigan <insert amusing quip here>
jsalter@ibmpa.awdpa.ibm.com (04/02/91)
In article <1991Apr1.210000.6909@engin.umich.edu> wross@caen.engin.umich.edu (Wendy Ross) writes: >I have a question. We also are compiling X11R4 with the suggested >patches. We did compile it with the -L option so that the clients >will use our X11R4 shared libraries instead of /usr/lib libraries. >Everything works just fine if the clients (ie xterm) is not suid. >xterm runs without problems, and finds the right library. However, >as soon as we make xterm suid root, it bombs out with the XCOFF >error, saying something about /usr/lib/libXt.a. Is there some >reason that suid programs only look in /usr/lib? Does anyone have >any other suggestions? As noted in the exec() subroutine info page: "If the new program requires shared libraries, the exec subroutine finds, opens, and loads each of them into the new process address space. The referenced counts for shared libraries in use by the issuer of the exec are decremented. Shared libraries are searched for in the directories listed in the LIBPATH environment variable. If any of these files is remote, the data is copied into local virtual memory." Also, as noted in the (*load)() subroutine info page: "The exec subroutine is similar to the load subroutine, except that exec does not have an explicit library path parameter; it has only the LIBPATH environment variable. Also, LIBPATH is ignored when the exec'd program has ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ more privilege than the caller, for example, in the case of an suid program." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Marc? John? Care to enhance this a bit? As for how to fix this? Got me. >Wendy Ross wross@caen.engin.umich.edu jim/jsalter IBM PSP, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter "For every SNAKE there is a mongoose". The commentary above is solely my own.