The immediate problem that I see is the following
LDADD= -L$(top_builddir)/src/.libs -lXbae \
-L$(top_builddir)/../Xm$(lib_version_suffix)/.libs \
@MOTIF_LIBS@ -lXm @X_LIBS@ -lXt ${X_PRE_LIBS} -lXext -lX11
${X_EXTRA_LIBS}
The second line ensures that Xm is picked up from the LessTif source tree, no
matter what was specified with --with-motif-libs, which is contained in
@MOTIF_LIBS@. Now if LessTif was not compiled, every thing will be fine,
because there will not be a libXm.so in the LessTif tree. On second thought, it
won't be fine because it will be picking up the wrong headers also.
This is one of the _many_ problems with compiling a library that depends on
another library that is being built at the same time.
The above example is from examples/caption/Makefile.am.
> This is probably because OpenMotif contains stuff that uses -lXp.
>
> This stuff (XmPrint) requires everyone who links Motif to also link
> -lXp, except on platforms that do this automatically through their
> shared library implementation.
>
> So this is an Xbae configuration bug.
>
> It would also be a configuration bug for every application which
> links -lXm without -lXp.
>
> Danny
>
> > Not too sure. I link apps all the time without specifying -lXp. I suspect
> > they are not really linking with OM. But I haven't tried to build Xbae
> > against OM. I'm giving it a wirl right now against my branch of OM. Well
> > it seems fine. It seems to fail with an xpm reference, but that is a
> > different problem. Ahhh, no it's not fine. It seems to be linking the
> > example apps against LessTif, regardless of the setting of
> > --with-motif-includes --with-motif-libs. Looks like a Xbae build problem
> > to me. It would probably work if Xbae was not in the LessTif source tree.
> >
> > > Rick,
> > >
> > > Is this really an Open Motif problem that we need to correct in the
> > > next distribution? (Pardon my ignorance, its been 25 years since I
> > > last did any real programming...)
> > >
> > > Mark
>
>
