[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Qt-3.1.1 under RedHat 8.0
From:       John Bell <jhbell () tpg ! com ! au>
Date:       2002-12-26 9:33:54
[Download RAW message or body]

On Tuesday 24 December 2002 14:36, James Richard Tyrer wrote:
> John Bell wrote:
> > The following is what's actually required:
> >
> > Firstly, DON'T make a libXft.so link to libXft2!  This will only cause
> > further confusion.
>
> I didn't say to do that.  I said to make a link:
>
> 	/usr/X11R6/lib/libXft.so -> /usr/lib/libXft.so.2.0
>

My reccomendation here was in response to most peoples first instinctual 
response (my own included) rather than to your post.  I agree that your 
method will work.  My own aversion to this approach is simply policy based - 
I don't mess with RedHat's installation setup and I isolate my non-RPM 
packages under /usr/local.  The purpose of this approach is to minimise 
exceptions and thus potential sources of error in doing upgrades, system 
rebuilds, new systems builds etc.  

> NOTE: if you install the FCPackage, you will have:
>
> [root@localhost lib]# ls -l libXft.so*
> lrwxrwxrwx    1 root     root           11 Dec 18 12:17 libXft.so ->
> libXft.so.2 lrwxrwxrwx    1 root     root           13 Dec 18 12:17
> libXft.so.1 -> libXft.so.1.2 -rwxr-xr-x    1 root     root        60571 Nov
> 25 01:08 libXft.so.1.2 lrwxrwxrwx    1 root     root           13 Dec 18
> 12:17 libXft.so.2 -> libXft.so.2.0 -rwxr-xr-x    1 root     root       
> 77681 Dec 18 12:21 libXft.so.2.0
>
> The: "libXft2.so" label is a RedHat invention.

Correct. 

>
> This *is* going to cause problems with OLD packages that require: Xft[1] if
> they aren't linked against a specific library version.
>
> On the other hand, if you patch Qt to use Xft2 then you are going to have
> to patch every new package that uses Xft (which uses version 2) as well. 
> So, you need to consider whether backward compatibility or forward
> compatibility is more important.
>

True enough.  Once again this is simply a matter of consistent application of 
the policy choice outlined above.  I agree that this was one of RH's odder 
choices and that it potentially raises more porting issues than most.  I 
guess that they simply wanted to remove any possible ambiguity with respoct 
to the meaning of "-lXft".  OTOH, having some form of consistent porting 
policy is a necessity if you're regularly setting up new systems.

> > Attached are some patches and a build script I used.  Note that the
> > script expects the source archive to be in /usr/local/src/sources and the
> > patches in /usr/local/src/sources/qt-x11-free-3.1.1-patches.  I have my
> > installscripts in /usr/local/src/sources/installscripts.  The build
> > installs under /usr/local/qt.  The odd recopying of the archive files is
> > to get over a shortcoming of qmake (it stupidly strips symbols from .a
> > archives).
> >
> > I'm pretty sure this is all that I did and it works fine for me on RH8.0.
>
> Are you certain which version of the: "Xft.h" header you build Qt with?
>

Yes.  On standard RH8.0 there's only one Xft.h file (under Xft2/X11/Xft).

> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

-- 

Regards,
John Bell,
BCM Research

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]