4 Sep
2011
4 Sep
'11
7:48 p.m.
Le Sun, 4 Sep 2011 13:03:53 -0500,
"Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> a écrit :
Good thinking! Although as a Debian/Ubuntu developer I could take
offence at your comment... ;-) It would be good thinking if I built Trinity with
autotools… it was
not the case, so I am clearly wrong.
And I didn't intend any offence, since I understand that Debian/Ubuntu
patches are not always intended to be merged upstream (the Qt3
dpkg-architecture patch is obviously in this case, for example).
Why does TDE use "lib" directory, since I
compiled for "lib64" ?
Is there a trick to change this ? (environment variable at
runtime ? cmake configuration flag ?)
It probably originates from a Debian/Ubuntu
patch:
-Debian/Ubuntu uses lib instead of lib64
-Debian/Ubuntu developers don't mind of the portability of their
patches -The Trinity source was based on KDE 3.5.10 with
Debian/Ubuntu patches
>
> Thanks
> Francois Andriot
TDE aims to be distribution agnostic. If you can identify where the
problem is, I will rectify it in SVN immediately.
Can you try the attached patch to see if it rectifies the problem?
Note that it ONLY works with packages that are built via Autotools
(i.e. arts, kdelibs, kdebase will NOT be affected by the application
of this patch--if the problem exists in kdelibs/kdebase please let me
know). Also, you will have to apply the patch and regenerate your
Autotools files (make -f admin/Makefile.common) before rebuilding
each Trinity module or application.
When I encountered this problem in May I
didn't even try to build
non-CMake parts of Trinity, but neither kdebase nor kdelibs would work
properly. I built qt3, qca and poppler-qt3 with the Slackware 13.0
build scripts, with which Patrick Volderking managed to have a working
x86_64 KDE 3.5.10.
Thanks!
Tim