AMBER Archive (2007)Subject: Re: [Fwd: Re: AMBER: xleap patch for xorg-7.3 ??]
From: Xuebin Qiao (xbqiao_at_gmail.com)
Date: Thu Nov 15 2007 - 00:59:58 CST
>If I may make a suggestion, rather than hack the configure script,
>why not limit the fix to the makefile in the patch? Something along
>the line of:
It is unwise to hack in makefile using non-portable features. Put all ugly
things into a single place would be more decent design.
>The only corner case I can think of that this might miss is a
>partial or messed up X installation.
maybe yes or maybe not, function dlsym is used when programmer need to load
certain dynamic library by hand, and it resides in libc.so. So I guess add
-lc may be ok, though some other unresolved symbols may appear too. :-) If
only this symbol missed, it would has nothing to with X, but may due to a
unsuccessful partial upgrading to the OS.
qxb
On Nov 15, 2007 2:51 AM, M. L. Dodson <activesitedynamics_at_comcast.net>
wrote:
> I sent this out last week, but it never appeared on the list.
> So here we go again.
>
> Bud Dodson
>
> -------- Original Message --------
> Subject: Re: AMBER: xleap patch for xorg-7.3 ??
> Date: Fri, 09 Nov 2007 10:39:15 -0600
> From: M. L. Dodson <activesitedynamics_at_comcast.net>
> Reply-To: activesitedynamics_at_comcast.net
> To: amber_at_scripps.edu
> References: <47335DA5.7070408_at_comcast.net>
> <20071109020339.GB4688_at_scripps.edu>
> <dbb230210711090626n296bb537g9dd67c03ecd5b4f1_at_mail.gmail.com>
>
> Xuebin Qiao wrote:
> > Hi,
> >
> > The Xorg7 has been designed to a new modularized architecture instead of
> > the old monolithic source tree. So it may break many old packages,
> > especially for those are linked with hand-coded linker options.
> >
> > qxb
> >
> > On Nov 9, 2007 10:03 AM, David A. Case <case_at_scripps.edu
> > <mailto:case_at_scripps.edu>> wrote:
> >
> > On Thu, Nov 08, 2007, M. L. Dodson wrote:
> > >
> > > I found the following patch to be necessary for successfully
> > > linking xaLeap with xorg-7.3
> > >
> >
> > > --- leap/src/leap/Makefile.orig 2007-10-03 09:59:
> > 50.000000000 -0500
> > > +++ leap/src/leap/Makefile 2007-11-08 12:08:59.000000000 -0600
> > > @@ -114,7 +114,7 @@
> > > # XlcDL.o(.text+0xe2): undefined reference to `dlsym'
> > > #
> > > XALEAP_LIB = ../Xraw/libXaw.a ../Wc/libWcLeap.a ../Xpm/libXpm.a
> \
> > > - ../Xmu/libXmu.a $(XLIBS) -lXt -lXext -lSM -lICE -lX11 $(LM)
> > -lpthread
> > > + ../Xmu/libXmu.a $(XLIBS) -lXt -lXext -lSM -lICE -lX11 -lXau
> > -lXdmcp $(LM) -lpthread
> > >
> > > OBJ = $(OA) $(OG) $(OO) $(OL)
> > >
> >
> > Thanks for the report. But some more information might help:
> >
> > What is the error when you don't have -lXau -lXdmcp specified?
> Do you
> > undertstand why xorg-7.3 needs these but not other
> X-implementations?
> >
>
> Unresolved symbols in the link. No, although it may have
> something to do with factoring the functionality of X,
> contemporaneously at least, with the build factorization qxb
> described above.
>
> > (extra credit:) how standard are libXau and libXdmcp? They seem to
> > be present
> > on IRIX, Cygwin and Linuces, but I don't know about AIX or MacOS
> > (for example).
> >
>
> I can speak only for recent FreeBSD X installs and MacOS 10.4.10
> (my laptop). On the mac, xdpyinfo says it is XFree86 4.4.0, and
> it is at least two years since I installed it (several OS minor
> version upgrades since then). I.e., it predates the xorg split
> from XFree86, I think. Both libs present on these OS types.
>
> > These "standard X" libraries are ancient...why would xorg move
> > things around
> > in a way almost guaranteed to break old programs?
> >
>
> The ABI is probably still intact, but the implementations may now
> call functions in the new libs. This may be associated with the
> functionality factorization I implied above.
>
> > I'm happy to make the above patch if it is safe for all machines.
> > Otherwise,
> > we'll have to add code to the configure script to special-case this
> > out.
> >
> > ...dac
> >
>
> If I may make a suggestion, rather than hack the configure script,
> why not limit the fix to the makefile in the patch? Something along
> the line of:
>
> XALEAP_LIB = ../Xraw/libXaw.a ../Wc/libWcLeap.a ../Xpm/libXpm.a \
> ../Xmu/libXmu.a $(XLIBS) -lXt -lXext -lSM -lICE -lX11
> <test for the existence of the libs>
> if (libs present)
> XALEAP_LIB += -lXau -lXdmcp $(LM) -lpthread
> else
> XALEAP_LIB += $(LM) -lpthread
>
> My SysV make-foo is not up to this test (I'm a Berkeley make kind
> of guy), but this should be possible, at least for gmake, I would
> think.
>
> The only corner case I can think of that this might miss is a
> partial or messed up X installation. It may give a misleading
> error message in that case.
>
> Bud Dodson
>
> --
> M. L. Dodson
> Business Email: activesitedynamics-at-comcast-dot-net
> Personal Email: mldodson-at-comcast-dot-net
> Phone: eight_three_two-56_three-386_one
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber_at_scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu
>
--
... there have been two really clean,
consistent models of programming so far:
the C model and the Lisp model.
These two seem points of high ground,
with swampy lowlands between them.
--Paul Graham
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu
|