DS9 and static linking, was Re: The meaning(s) of $DISPLAY
DS9 and static linking, was Re: The meaning(s) of $DISPLAY
- Subject: DS9 and static linking, was Re: The meaning(s) of $DISPLAY
- From: Ben Byer <email@hidden>
- Date: Tue, 20 Nov 2007 02:31:20 -0800
On Nov 19, 2007, at 7:15 AM, Jamie Kennea wrote:
On Nov 19, 2007, at 10:04 AM, Derek Fawcus wrote:
What is _gained_ my using an alternate socket, that could not have
been achieved
without it. Similarly what is _gained_ by defining a new
interpretation for DISPLAY,
that could not have been hidden in the x11 transport library?
So far all I can see is that two other programs (xauth, ssh) had
to be updated
to cope with the new DISPLAY contents.
Other programs are affected. For example, the standard astronomer's
tool "ds9" just doesn't work with the new DISPLAY format.
Please see http://developer.apple.com/qa/qa2001/qa1118.html .
ds9 is a very strangely built program -- and I speak only from the
perspective of someone who spends all day looking at how open-source
projects are compiled. (I've received enough email to know that it's
a very useful and widely used program!)
(Note: confusingly, there are both Darwin versions and Mac OS X
versions of ds9; the MacOSX build does not use X11, so I'm talking
about the Darwin version.)
Among other things, they acknowledge the above note, and then
explicitly ignore it. From saods9/ds9/Makefile:
#--------------------------darwin intel
# darwin can't be linked static
# also, the libs always need ranlib
ifeq ($(ARCH),darwinintel)
ds9Base : $(OBJS) $(LIBS)
$(RM) $@
ranlib $(LIBS)
$(CXX) ${OPTS} \
-o $@ $(OBJS) $(LIBS) \
-lstdc++ \
$(X11LIB)/libX11.a \
$(EXTLIB)
endif
The problem there is the libX11.a (a static library) -- it should be
libX11.dylib (the dynamic library).
For those not following, the use of libX11.a means that the ds9 binary
for Darwin uses the copy of the X11 code from the system used to build
the binary; with a slight change, it would have linked against the
runtime system version of libX11, which is why the vast majority of
X11 apps built on Tiger still worked correctly on Leopard, even with
the enhanced $DISPLAY.
Luckily it can be recompiled under Leopard
No, it can't -- at least not without modifying the above line, as we
no longer ship libX11.a (to prevent this sort of thing from happening
in the future).
(although right now the people in charge of DS9 are advising that
Leopard X11 users simply set their DISPLAY variable to ":0", advise
which might raise a few hackles around here),
Nah, it's a fine workaround for this problem. It's Good Enough (tm).
but I'm wondering how long before someone comes along with a
commercial X11 based app that breaks because of this change
(although admittedly this is unlikely as Macs don't have too many
commercial X11 apps).
Although I'd usually let Dr. Ernie respond to statements like that, I
expect he's probably actually taking his vacation. Instead, I'll
respond, but I'll probably get more huffy than he would have.
Several high-profile X apps broke on Leopard, although it was
generally due to issues with their .app bundle X11 launchers; DS9 is
the only major X application that was reported to Apple as having been
broken by the $DISPLAY change. This was probably due to a number of
factors:
* Commercial software developers have the money to participate in
Apple's Developer Seed program; they would have caught this issue
before Leopard's launch, and fixed it in their program.
* Many academic and scientific users participate in Apple's Customer
Seeding program; they would have reported this issue to Apple so that
we could reconsider the change, notify the developer or develop a
workaround, as appropriate
* I've never seen another program that statically linked against libX11.
My feeling is that if someone like Sun made a change to the DISPLAY
variable like this they'd break hundreds of commercial apps and
their users would be screaming, but with Apple X11 is for
"hobbyists" or "developers" who don't mind fixing apps that it breaks.
No, this would not have happened if Sun made this change.
From the same Makefile:
--------------------------solarisx86 i386
ifeq ($(ARCH),solarisx86)
ds9Base : $(OBJS) $(LIBS)
$(RM) $@
rm -f libstdc++.a
ln -s `$(CXX) ${OPTS} -print-file-name=libstdc++.a` .
$(CXX) -static-libgcc ${OPTS} \
-o $@ $(OBJS) $(LIBS) \
-Wl,-Bstatic -L. -lstdc++ \
-Wl,-Bdynamic -L$(X11LIB) -lX11 -lXext \
/usr/lib/libsocket.so /usr/lib/libnsl.so /usr/lib/libdl.so
rm -f libstdc++.a
endif
They explicitly linked against the dynamic X11 library. In fact, this
is the case for every platform except Darwin.
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden