hi,
sorry if this is a double reply (this time, reply-all)
As said in first reply, I disagree.
NOTE: libXft2 is not some Xft replacement. It is written by Keith
Packard and installed to /usr/X11R6/lib/ by default: not /usr/lib.
This is contrary to the comments of Daniel Stone, who apparently did no
research before giving snide reply and hanging up.
None of XFree86, Debian, KDE, nor Gnome has moved their compiles to
point to /usr/lib. They shouldn't on a linux system.
Below is a snipet from gnome.org's bugzilla. Dated '2002 bug the same
problem - up to at least '2003 there are dup reports of it.
And can we thank Redhat? Likely so. What do we be it isn't broken in
their $$ version of linux? I've have previous experiences with
reporting bugs to Redhat. A broken ps and a refusal to fix or accept
code comes to mind.
Only package gtk does this: and only for ONE of the xlibs. Which is
likely an oversight.
if test $pango_omitted_x_deps = yes ; then
# Old versions of Xft didn't necessarily include -lX11 in the output
x_libs="`pkg-config --libs xft` -lX11 $X_EXTRA_LIBS"
fi
Sat Mar 2 14:32:50 2002 Owen Taylor <[EMAIL PROTECTED]>
* configure.in: Default to --disable-gtk-doc (avoid Jade
breakage) and --disable-static (static linking causes
problems with Xft changes.)
* GTK+-2.4 now requires version 2 of Xft; old fashioned core X
fonts are no longer supported.
* Try to build libraries with only shared library dependencies on Xft to
deal with transition to Xft2 [Owen]
-----------------------------------------------------
Now I see. libxft2 is the new lib, which installs to /usr/lib since it
has nothing to do with XFree86.
gtk's pango support was adjusted by Redhat to be incompatible with
XFree86, to use only libxft2.
WAIT...
That still doesn't explain why I got the message about libXft to begin with.
From Bugzilla
http://bugzilla.gnome.org/show_bug.cgi?id=86150
=======================================================================
Bug 86150: Inability to even log in if your Xft is broken High
priority
Opened: 2002-06-21 12:05
Product: pango
Component: general
Version: unspecified
Status: NEW
Priority: High
Severity: critical
Reporter: [EMAIL PROTECTED] (Jim Gettys)
If you happen to have a broken Xft (as I did; Keith has since fixed this
bug), Gnome logs you in, but the panel crashes if it cannot find any fonts.
You may get (in your .xsession-errors file, or say, from
gnome-font-properties) complaints that it can't find any fonts.
The panel eventually exists; various other apps have similar behavior.
If no client side fonts can be found, we'd have a much more robust
system that would not fail in a completely obscure way (I end up with
a completely blank screen!) if it would fail back to core fonts.
This problem could occur other other circumstances, like messed up
XftConfig files, I suspect.
------- Additional Comment #1 From Luis Villa 2002-06-25 21:06 -------
Jim: did we decide that this is a gtk bug?
------- Additional Comment #2 From Owen Taylor 2002-06-25 21:34 -------
It's a Pango RFE. I wouldn't call it a bug.
(Pointing Xft at a particular file turns out to work
less than perfectly so it will take some work.)
There are various other Pango bugs which are sitting
on 1.2 or future milestones with "the only way
to do better is to ship a font with Pango" so its
sort of a dup of that.
<<<<<<<<< SEVERAL MORE DUPS >>>>>>>>>>>>
------- Additional Comment #6 From [EMAIL PROTECTED] 2003-11-02 10:25 -------
*** Bug 111471 has been marked as a duplicate of this bug. ***
-----------------------------------------------------------------------
I now I remember. I couldn't open xterm until I fixed the bad linkage
concerting libxft?
Of course once I did, I had to fix fonts dirs so adobe fonts could be
found (another bug? another story).
-------------------------------------------------------------------------
thanks,
[EMAIL PROTECTED]
[EMAIL PROTECTED]
PS
Below, we see /usr/lib/libXft directly, which is wrong. A damn
peritious thing. Difficult to find how it *became* that way.
If you look *carefully* you see /usr/lib/libXft.so is mentioned as an
absolute filename.
If you then look at the blabber of Redhat "coder" in the snippet of
Changelog above you see the magic. There is talk about problems with
temporarily having to meantion libXft directly. Ahh.
Am I good? Or does Redhat suck? Ha ha....
Have fun!
-----------------------------------------------------------
gtk/libgtk-x11-2.0.la:dependency_libs='
/mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk/l
ibgdk-x11-2.0.la -L/usr/X11R6/lib -lXrandr -lXinerama -lXext -lXft
-lfreetype -l
z -lXrender -lfontconfig
/mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk-pixbuf/libgdk_pi
xbuf-2.0.la -lX11 /usr/lib/libpangoxft-1.0.la /usr/lib/libpangox-1.0.la
/usr/lib
/libpango-1.0.la /usr/lib/libatk-1.0.la /usr/lib/libgobject-2.0.la
/usr/lib/libg
module-2.0.la -ldl /usr/lib/libglib-2.0.la -lm '
gtk/gtk-query-immodules-2.0:relink_command="(cd
/mnt/hda4/hog/tmp/gnome/gtk+-2.4
.3/gtk; { test -z \"\${LIBRARY_PATH+set}\" || unset LIBRARY_PATH || {
LIBRARY_PA
TH=; export LIBRARY_PATH; }; }; { test -z \"\${COMPILER_PATH+set}\" ||
unset COM
PILER_PATH || { COMPILER_PATH=; export COMPILER_PATH; }; }; { test -z
\"\${GCC_E
XEC_PREFIX+set}\" || unset GCC_EXEC_PREFIX || { GCC_EXEC_PREFIX=; export
GCC_EXE
C_PREFIX; }; }; { test -z \"\${LD_RUN_PATH+set}\" || unset LD_RUN_PATH
|| { LD_R
UN_PATH=; export LD_RUN_PATH; }; };
PATH=\"/usr/local/sbin:/usr/sbin:/sbin:/usr/
local/bin:/usr/bin:/bin:/usr/X11/bin:/home/scripts:/usr/games:/usr/lib/postgresq
l/bin\"; export PATH; gcc -g -O2 -Wall -o \$progdir/\$file
queryimmodules.o ./.
libs/libgtk-x11-2.0.so
/mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk/.libs/libgdk-x11-2
.0.so -L/usr/X11R6/lib /usr/lib/libatk-1.0.so
../gdk-pixbuf/.libs/libgdk_pixbuf-
2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lXrandr -lXinerama -lXext
/usr/lib/libXft
.so /usr/lib/libfreetype.so -lz -lXrender -lfontconfig -lX11
/usr/lib/libpangoxf
t-1.0.so /usr/lib/libpangox-1.0.so /usr/lib/libpango-1.0.so
/mnt/hda4/hog/tmp/gn
ome/gtk+-2.4.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so
/usr/lib/libgmodule-2.0.so
-ldl /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -lm -Wl,--rpath
-Wl,/mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gtk/.libs -Wl,--rpath
-Wl,/mnt/hda4/hog/tmp/gnome
/gtk+-2.4.3/gdk/.libs -Wl,--rpath
-Wl,/mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk-pix
buf/.libs -Wl,--rpath -Wl,/usr/local/lib)"
-----------------------------------------------------------
Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
#261854: xlibs: some softlinks not made correctly, installer fails to upgrade,
which was filed against the xlibs package.
It has been closed by one of the developers, namely
Daniel Stone <[EMAIL PROTECTED]>.
Their explanation is attached below. If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact the developer, by replying to this email.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Received: (at 261854-done) by bugs.debian.org; 28 Jul 2004 16:26:43 +0000
From [EMAIL PROTECTED] Wed Jul 28 09:26:42 2004
Return-path: <[EMAIL PROTECTED]>
Received: from fooishbar.org (tycho.fooishbar.org) [131.252.208.81] (postfix)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BprGM-0007U9-00; Wed, 28 Jul 2004 09:26:42 -0700
Received: by tycho.fooishbar.org (Postfix, from userid 1000)
id ADB28E9C036; Wed, 28 Jul 2004 09:26:42 -0700 (PDT)
Date: Thu, 29 Jul 2004 02:26:42 +1000
From: Daniel Stone <[EMAIL PROTECTED]>
To: "John D. Hendrickson" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#261854: xlibs: some softlinks not made correctly, installer
fails to upgrade
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="pN9MePJoZbRKbUk1"
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
X-GnuPG-Key: 3CED7EFD
User-Agent: Mutt/1.5.6+20040523i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
--pN9MePJoZbRKbUk1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 28, 2004 at 12:01:38PM -0400, John D. Hendrickson wrote:
Two things. One, xlibs did not install files correctly. Two, all X pack=
ages
now require a new directory structure (which I hate). Anyway the install=
er
does nothing to provide this new directory structure. I made a script wh=
ich
does this which has done this for me on several machines.
=20
Just did a "dist-upgrade" to sarge
=20
for libs I had xlib's /usr/lib/libXft.so and a couple others in /usr/lib
=20
These are xlibs, not usr libs, they shouldn't even have links into /usr/l=
ib
=20
After remaking the links the installer goofed, it worked. Somehow the
installer doesn't take into account the present / previous state when mak=
ing
its links.
=20
I found the ONLY reason libXft need to be in /usr/lib is due to gtk. Whi=
le
all else of gnome correctly uses X11R6/lib, gtk uses /usr/lib, oddly. Fix
that and you fix allot of confusion. The ./configure for gtk is just flat
wrong. And using ./configure --prefix=3DPATH won't help - becuase it is =
really
wrong - a goof up.
/usr/X11R6 is being moved away from by upstream and everyone else sane
because it's beyond a joke nowadays. Many things -- not just Xft;
fontconfig, Xcursor, Xrender, et al -- are in /usr/lib now. You haven't
been near specific enough. What failed? What 'goofed'? Which installer
were you using? Did you do a complete dist-upgrade? If so, why is your
xlibs package still at 4.1.0-16, which is the woody version?
Closing this bug report as utterly bogus and invalid unless submitter
provides a compelling rationale otherwise.
--=20
Daniel Stone <[EMAIL PROTECTED]
=2Eorg>
Debian: the universal operating system http://www.debia=
n.org
--pN9MePJoZbRKbUk1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBB9PCcPClnTztfv0RAqVkAJ4gsiSS9/Nydu/IUr4myg538ZFa7wCfdbtv
IQwkPEbv7/3W9E2FB0mwD9s=
=1jQH
-----END PGP SIGNATURE-----
--pN9MePJoZbRKbUk1--
