YK> Hello, YK> I usually use Athena widgets to build XEmacs, but today I tried using YK> openmotif to build XEmacs (CVS updated today). But the configure YK> script failed to detect Motif environment. Previously I could compile YK> some Motif-based applications on this host, so I believe my YK> configuration is sane. YK> I used the following options. YK> ./configure --compiler=gcc295 --with-mule --without-xim --error-checking=all --debug --with-xfs --with-widgets=motif --without-canna YK> I tried to add -lXp and I could compile the test code. Actually I YK> don't know what libXp.a is, but I guess configure should detect the YK> existence of this library. This is rather surprising, since I've never heard of -lXp, and previous versions of Motif didn't have any such thing. It's hard to believe the Motif people would have introduced a change in the way the libs should be used by the application. My guess is that Motif was not properly built on this platform. Either libXp should be statically linked into libXm, or, if libXp is dynamically linked into libXm, libXm should be built in such a way that internal references to libXp are automatically resolved. Check for unresolved symbol references when building libXm. I bet that libXp was named for p = `private'. Martin

Y> On Thu, 3 Aug 2000 14:41:43 +0900 (JST), Y> Martin Buchholz <martin(a)xemacs.org&gt; said: Y> I remembered that I merely installed the binary distribution of Y> open-motif-2.1.30 and open-motif-devel-2.1.30 (provided by Y> openmotif.opengroup.org) using the ports mechanism of FreeBSD. Well, I just installed OpenMotif on my Linux Box, and everything builds fine. So I guess this is just a temporary build problem on FreeBSD. You should not have to specify -lXp, and I will not change XEmacs to autodetect -lXp. You could try to help the Freebsd project to fix their bug with building OpenMotif. Of course, they'll probably point the finger back here. However, the new XEmacs I built is crashing. I won't claim this is an OpenMotif bug without investigating. Martin

Darryl> It's not a FreeBSD bug. Darryl> If you grab the OpenMotif sources (R2.1.30), you'll see lots of Darryl> references to Xprint routines. In particular, see the source file: Darryl> motif/lib/Xm/PrintS.c Darryl> As far as I can tell, the OpenMotif print code is not conditionalized; Darryl> it's always compiled. I don't see how you can use OpenMotif without -lXp. There is no libXp in my OpenMotif 2.1.30 installed on Linux. Functions from PrintS.c end up in libXm.so, like they're probably supposed to. If motif/lib/Xm/PrintS.c was supposed to contribute to libXp.so, why isn't it in motif/lib/Xp/PrintS.c ? (martin＠lasker) /usr/local/dt/lib $ ldd libXm.so libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x401b5000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x401ff000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40208000) libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x4021e000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40225000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40232000) libc.so.6 => /lib/libc.so.6 (0x402d7000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) (martin＠lasker) /usr/local/dt/lib $ nm libXm.so | g XmPrintSetup 00144f34 T XmPrintSetup

Darryl> Martin Buchholz <martin(a)xemacs.org&gt; wrote: Darryl> Yes, but your copy of OpenMotif references libXp -- see below. Darryl> You have it backwards (or maybe I'm misunderstanding your Darryl> english). There are new (?) Motif print routines in OpenMotif, and Darryl> these routines call functions in the X print library (libXp). Darryl> ^^^^^^^^^^ Darryl> Huh? This looks like libXp to me. OOOOPS! I stand corrected. Refuted by my own evidence! OK, I thought libXp was part of OpenMotif, but no, it's merely *used* by OpenMotif. libXp is part of X11R6. Darryl> Hmmm. I'm not very familiar with Linux. Does Linux have some kind Darryl> of deferred linking, where symbols in shared libraries are not resolved Darryl> at link time but at runtime, instead? Darryl> [ Oh. Ah. If I recall correctly, FreeBSD 3.X (which Kasahara-san is Darryl> using), did not have deferred linking; all symbols in all libraries Darryl> had to be resolved (must exist and be found) at link time. FreeBSD Darryl> 4.X (and probably Linux) use deferred linking, where symbols in shared Darryl> libraries aren't checked and resolved until runtime (this means that Darryl> unresolved symbols like XpStartPage would cause a core dump at runtime Darryl> if the symbol could not be found). This is probably what you're Darryl> seeing. I'd bet that your XEmacs would dump core if it tried to Darryl> reference a Motif print function (which references libXp, which Darryl> doesn't exist on your system). This probably means that someone Darryl> (you?) will have to change configure to check for libXp on those Darryl> systems for which deferred linking is not used. ] Darryl> [ P.S. -- I'm not sure if the correct term is really "deferred linking", Darryl> but that's what I've been calling it. ] (martin＠lasker) ~/src $ gcc xm.c /tmp/cc03owBq.o: In function `main': /tmp/cc03owBq.o(.text+0xc): undefined reference to `XmStringFree' (martin＠lasker) ~/src $ gcc xm.c -L /usr/local/dt/lib -lXm (martin＠lasker) ~/src $ cat xm.c int main (int argc, char *argv[]) { XmStringFree(); } Look at the above. This is the correct way for the system to behave, I believe. If app xx uses a symbol from library ll, then xx should only need to link with ll. If ll in turn needs some other library mm, then that should be transparent to xx, and taken care of at the time that ll is built. Despite my major gaffe above, I believe my point is still valid. Note that libXm.so's dependencies are recorded in the libXm.so file. So when a user links with libXm.so, the linker is smart enough to (recursively) link in libXp.so from elsewhere. If the BSD linker is so stupid that it is impossible to use -lXm without also specifying -lXp, then BSD as a whole is horribly broken. But I don't believe that. Here is some documentation from GNU ld, apparently used by freebsd: `-rpath-link DIR' When using ELF or SunOS, one shared library may require another. This happens when an `ld -shared' link includes a shared library as one of the input files. When the linker encounters such a dependency when doing a non-shared, non-relocateable link, it will automatically try to locate the required shared library and include it in the link, if it is not included explicitly. In such a case, the `-rpath-link' option specifies the first set of directories to search. The `-rpath-link' option may specify a sequence of directory names either by specifying a list of names separated by colons, or by appearing multiple times. The linker uses the following search paths to locate required shared libraries. 1. Any directories specified by `-rpath-link' options. 2. Any directories specified by `-rpath' options. The difference between `-rpath' and `-rpath-link' is that directories specified by `-rpath' options are included in the executable and used at runtime, whereas the `-rpath-link' option is only effective at link time. 3. On an ELF system, if the `-rpath' and `rpath-link' options were not used, search the contents of the environment variable `LD_RUN_PATH'. 4. On SunOS, if the `-rpath' option was not used, search any directories specified using `-L' options. 5. For a native linker, the contents of the environment variable `LD_LIBRARY_PATH'. 6. The default directories, normally `/lib' and `/usr/lib'. If the required shared library is not found, the linker will issue a warning and continue with the link. Martin

Darryl> Martin Buchholz <martin(a)xemacs.org&gt; wrote: Darryl> It's been a long time, and my memory pretty fuzzy, but I think Darryl> FreeBSD 3.X (an old version, which Kasahara-san is using) acted this Darryl> way. Newer versions of FreeBSD (4.X and later) don't act this way, and Darryl> "act correctly". Darryl> However, what do you expect people to do if they want to link Motif Darryl> statically, which older version of XEmacs does support? Are we going to Darryl> take away this ability? I'm still not convinced that this isn't a build problem with OpenMotif on this particular platform. Since the beginning of time people have built Motif applications using -lXm -lXt -lX11, and they shouldn't have to start adding an extra library for an extension they don't use. So my position remains that the XEmacs maintainers will do nothing for this problem (except finger-point). Martin

Martin Buchholz writes: Isn't there something called the X Printing Library?

At 09:20 AM 8/3/00 -0700, Darryl Okahata wrote: Sounds like a coding opportunity for Kirill .... andy -------------------------------------------------------------- Dr Andy Piper Principal Consultant, BEA Systems Ltd