[PATCH xserver] dmx: fix linking again by brute-forcing

[Mihail Konev]

On Ubuntu 17.04 daily, the following error is seen,
(disappears when librender.a is put before libos.a on the resulting
collect2 linker command line (seen by CFLAGS='-v')):

  ../../render/.libs/librender.a(glyph.o): In function `HashGlyph':
  /mnt/xserver/render/glyph.c:168: undefined reference to `x_sha1_init'
  /mnt/xserver/render/glyph.c:174: undefined reference to `x_sha1_update'
  /mnt/xserver/render/glyph.c:177: undefined reference to `x_sha1_update'
  /mnt/xserver/render/glyph.c:180: undefined reference to `x_sha1_final'
  collect2: error: ld returned 1 exit status
  Makefile:763: recipe for target 'Xdmx' failed

Align XDMX_LIBS to be "... RANDR RENDER ... PRESENT ...",
as in all other DDX-es; but this wouldn't help:

  ../../present/.libs/libpresent.a(present.o): In function `present_check_output_slaves_active':
  /mnt/xserver/present/present.c:126: undefined reference to `RRHasScanoutPixmap'
  collect2: error: ld returned 1 exit status

Then move PRESENT: "... PRESENT RANDR RENDER ...":

  ../../dix/.libs/libdix.a(pixmap.o): In function `PixmapStartDirtyTracking':
  /mnt/xserver/dix/pixmap.c:204: undefined reference to `RRTransformCompute'
  collect2: error: ld returned 1 exit status

Then align them as "... PRESENT ...LIBDIX... RANDR RENDER ...",
which somehow works.

Then moving PRESENT as "...LIBDIX... PRESENT RANDR RENDER ...",
or surrounding the original RANDR with RENDER or also PRESENT as
"...LIBDIX... PRESENT RANDR RENDER ..." would give the original
HashGlyph error.

Regressed-in: 3ef16dfb ("dmx: fix linking")
Suggested-by: Michel Dänzer <michel at daenzer.net>
Reported-by: Byeong-ryeol Kim <brofkims at gmail.com>
Signed-off-by: Mihail Konev <k.mvc at ya.ru>
---
I was probably wrong in the previous message, as why "linking into"
would be different from listing a library multiple times.

On the other hand, looking at the above, it seems that saying
"randr depends on render" is less a guessing-game than finding
out where to put PRESENT. (Since the "nightmare").

That is, this patch, while smaller and more conservative,
might as well be risky, and is at least less explicit.
(I.e. wouldn't it be harder to figure out whether to reorder the libs,
or to list some the second time, then just to add a LIBADD,
should it break on another toolchain?)
(Also maybe it was not Ubuntu, but gcc 6.3.0).

 configure.ac       | 2 +-
 hw/dmx/Makefile.am | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4dcf8b5c27a0..ddd0a61c9d97 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2330,7 +2330,7 @@ if test "x$DMX" = xyes; then
 	fi
 	DMX_INCLUDES="$XEXT_INC $RENDER_INC $RECORD_INC"
 	XDMX_CFLAGS="$DMXMODULES_CFLAGS"
-	XDMX_LIBS="$FB_LIB $MI_LIB $XEXT_LIB $RENDER_LIB $RECORD_LIB $XI_LIB $XKB_LIB $XKB_STUB_LIB $DRI3_LIB $PRESENT_LIB $MIEXT_SYNC_LIB $MIEXT_SHADOW_LIB $MIEXT_DAMAGE_LIB $COMPOSITE_LIB $DAMAGE_LIB $MAIN_LIB $DIX_LIB $RANDR_LIB $CONFIG_LIB $OS_LIB $FIXES_LIB"
+	XDMX_LIBS="$FB_LIB $MI_LIB $XEXT_LIB $PRESENT_LIB $RECORD_LIB $XI_LIB $XKB_LIB $XKB_STUB_LIB $DRI3_LIB $MIEXT_SYNC_LIB $MIEXT_SHADOW_LIB $MIEXT_DAMAGE_LIB $COMPOSITE_LIB $DAMAGE_LIB $MAIN_LIB $DIX_LIB $CONFIG_LIB $RANDR_LIB $RENDER_LIB $OS_LIB $FIXES_LIB"
 	XDMX_SYS_LIBS="$DMXMODULES_LIBS"
 	AC_SUBST([XDMX_CFLAGS])
 	AC_SUBST([XDMX_LIBS])
diff --git a/hw/dmx/Makefile.am b/hw/dmx/Makefile.am
index 38d6ac409e76..eef84cb66a76 100644
--- a/hw/dmx/Makefile.am
+++ b/hw/dmx/Makefile.am
@@ -80,8 +80,7 @@ XDMX_LIBS = \
 
 Xdmx_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG)
 Xdmx_DEPENDENCIES= $(XDMX_LIBS)
-Xdmx_LDADD = $(XDMX_LIBS) $(XDMX_SYS_LIBS) $(XSERVER_SYS_LIBS) \
-             $(top_builddir)/render/librender.la
+Xdmx_LDADD = $(XDMX_LIBS) $(XDMX_SYS_LIBS) $(XSERVER_SYS_LIBS)
 
 relink:
 	$(AM_V_at)rm -f Xdmx$(EXEEXT) && $(MAKE) Xdmx$(EXEEXT)
-- 
2.9.2