Sources Bugzilla – Bug 11306
Built libXfont static-only
Last modified: 2010-08-09 05:49:10 UTC
From my comment in the xserver .cygport:
# libXfont defines weak symbols which are overridden in dix/dixfonts.c, but
# current weak symbol handling requires static linking to work correctly. But
# we can't ship a static-only libXfont because xfs requires it shared, otherwise
# you get multiple definitions during linking thanks to the xtrans code.
Or can we? I haven't tried this recently, but we're not shipping xfs anyway.
The other programs which dep libXfont1 are bdftopcf and mkcfm.
There's another problem: with libtool 2.2, -static means link libtool libraries
static-only, the flag does not affect executable linkage. The correct flag
would be -static-libtool-libs, but the server needs dynamic linkage of at least
libGL (for the swrast hack), so better to just avoid this altogether.
Shipped libXfont-1.4.1-2 as static only, but that won't help when building the
entire stack from git (e.g. with jhbuild). One possible solution would be to
remove -no-undefined from libXfont_la_LDFLAGS, in which case libtool will refuse
to build a shared library on PE/COFF platforms. This would affect Xming as well,
and it may still break xfs (not that I care). Thoughts?
Or better still, fix the libXfont interface, so it doesn't rely on weak symbols
to work. Then we can dynamically link and everyone is happy.
Perhaps easier said then done. Here are the suspects:
./src/stubs/cauthgen.c:#pragma weak client_auth_generation
./src/stubs/csignal.c:#pragma weak ClientSignal
./src/stubs/delfntcid.c:#pragma weak DeleteFontClientID
./src/stubs/errorf.c:#pragma weak ErrorF
./src/stubs/fatalerror.c:#pragma weak FatalError
./src/stubs/findoldfnt.c:#pragma weak find_old_font
./src/stubs/getcres.c:#pragma weak GetClientResolutions
./src/stubs/getdefptsize.c:#pragma weak GetDefaultPointSize
./src/stubs/getnewfntcid.c:#pragma weak GetNewFontClientID
./src/stubs/gettime.c:#pragma weak GetTimeInMillis
./src/stubs/initfshdl.c:#pragma weak init_fs_handlers
./src/stubs/regfpefunc.c:#pragma weak RegisterFPEFunctions
./src/stubs/rmfshdl.c:#pragma weak remove_fs_handlers
./src/stubs/servclient.c:#pragma weak serverClient
./src/stubs/setfntauth.c:#pragma weak set_font_authorizations
./src/stubs/stfntcfnt.c:#pragma weak StoreFontClientFont
./src/util/atom.c:#pragma weak MakeAtom
./src/util/atom.c:#pragma weak ValidAtom
./src/util/atom.c:#pragma weak NameForAtom
./src/util/miscutil.c:#pragma weak serverGeneration
./src/util/miscutil.c:#pragma weak register_fpe_functions
davek has confirmed that binutils is still not up to the task:
and here is some discussion from the previous Cygwin/X maintainers:
Although I'm not sure that the solution proposed there is the correct one.
Note that mkcfm should be obsoleted if it isn't already
See also https://bugs.freedesktop.org/show_bug.cgi?id=5553
Author: Yaakov Selkowitz <yselkowitz@...>
Date: Wed Apr 14 05:58:28 2010 -0500
Revert "Bug #6247: Fix build on Cygwin"
libtool requires the '-no-undefined' flag in order to create shared
libraries on PE/COFF platforms (Cygwin/MinGW); on other platforms this
flag has no effect.
The problem with libXfont is that PE weak symbols do not behave exactly
as they do on ELF platforms. Since PE binaries (both executables and
libraries) must have all symbols resolved at link time, there is no way
for the real symbols in xserver to "displace" those in libXfont at
runtime, so the result is that libXfont uses its stubs, which do
nothing, and xserver ends up unable to find its fonts.
Solving this will require either significant changes to libXfont or some
major improvement to the toolchain to handle this case. Until that
happens, removing '-no-undefined' will result in a static-only library
on these platforms, which is the only currently working solution.
This reverts commit 69c4ae1e3e14a58bc2eb9b9b8820dc7183b82a67.