Bug 11306

Summary: Built libXfont static-only
Product: cygwin Reporter: Yaakov Selkowitz <yselkowi>
Component: Cygwin/XAssignee: Yaakov Selkowitz <yselkowi>
Status: RESOLVED FIXED    
Severity: normal CC: jon.turney
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description Yaakov Selkowitz 2010-02-22 09:55:14 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.
Comment 1 Yaakov Selkowitz 2010-02-25 09:31:33 UTC
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?
Comment 2 Jon Turney 2010-02-25 14:56:32 UTC
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.
Comment 3 Yaakov Selkowitz 2010-03-25 18:06:11 UTC
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
Comment 4 Yaakov Selkowitz 2010-04-14 18:16:29 UTC
davek has confirmed that binutils is still not up to the task:

http://cygwin.com/ml/cygwin/2010-04/msg00281.html

and here is some discussion from the previous Cygwin/X maintainers:

http://cygwin.com/ml/cygwin-xfree/2003-10/msg00292.html

Although I'm not sure that the solution proposed there is the correct one.
Comment 5 Jon Turney 2010-06-28 15:36:33 UTC
Note that mkcfm should be obsoleted if it isn't already

See also https://bugs.freedesktop.org/show_bug.cgi?id=5553
Comment 6 Yaakov Selkowitz 2010-08-09 05:49:10 UTC
commit c482a2c104aa5cd1a265c2ca310a308dcc418fe7
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.

    http://sourceware.org/bugzilla/show_bug.cgi?id=11306
    http://cygwin.com/ml/cygwin/2010-04/msg00281.html

    This reverts commit 69c4ae1e3e14a58bc2eb9b9b8820dc7183b82a67.