Hello, I sucessfully built kdebase from SVN.
When packaging with default RHEL options, the desktop is unusable, it starts but many program do not run (kwin ...).
$ kwin KWin: No window decoration plugin library was found. KWin will now exit...
When clicking "my computer" icon, a popup appears: There was an error loading the module Navigation Panel. The diagnostic is: Library files for "konq_sidebar.la" not found in paths.
After stracing kwin, I found that it was trying to access a file 'kwin3_plastik.la' in many paths, but *all* of them prefixed with "lib". (e.g: /opt/trinity/lib/kwin3_plastik.la ...)
But in my build, the TDE libraries are installed under /opt/trinity/lib64 . (this is the RHEL/Fedora default on x86_64) I do not have a directory /opt/trinity/lib at all.
If I symlink "lib" to "lib64", everything works. If I build directly under /opt/trinity/lib , everything works too (of course).
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 ?)
Thanks Francois Andriot
Le Sun, 04 Sep 2011 12:21:21 +0200, Francois Andriot francois.andriot@free.fr a écrit :
Hello, I sucessfully built kdebase from SVN.
When packaging with default RHEL options, the desktop is unusable, it starts but many program do not run (kwin ...).
$ kwin KWin: No window decoration plugin library was found. KWin will now exit...
When clicking "my computer" icon, a popup appears: There was an error loading the module Navigation Panel. The diagnostic is: Library files for "konq_sidebar.la" not found in paths.
After stracing kwin, I found that it was trying to access a file 'kwin3_plastik.la' in many paths, but *all* of them prefixed with "lib". (e.g: /opt/trinity/lib/kwin3_plastik.la ...)
But in my build, the TDE libraries are installed under /opt/trinity/lib64 . (this is the RHEL/Fedora default on x86_64) I do not have a directory /opt/trinity/lib at all.
I had the same problem with Slackware64 4 months ago (Slackware64 uses lib64 too): no /opt/kde3/lib64/kde3 libraries were found (but I didn't know strace, so I didn't find the origin of the problem).
If I symlink "lib" to "lib64", everything works. If I build directly under /opt/trinity/lib , everything works too (of course).
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
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sunday 04 September 2011 15:36:44 /dev/ammo42 wrote:
I had the same problem with Slackware64 4 months ago (Slackware64 uses lib64 too): no /opt/kde3/lib64/kde3 libraries were found (but I didn't know strace, so I didn't find the origin of the problem).
I think this is a freedesktop standard. OpenSUSE also uses /usr/lib64 and /opt/kde3/lib64
Le 04/09/2011 19:11, Ilya Chernykh a écrit :
On Sunday 04 September 2011 15:36:44 /dev/ammo42 wrote:
I had the same problem with Slackware64 4 months ago (Slackware64 uses lib64 too): no /opt/kde3/lib64/kde3 libraries were found (but I didn't know strace, so I didn't find the origin of the problem).
I think this is a freedesktop standard. OpenSUSE also uses /usr/lib64 and /opt/kde3/lib64
I've just rebuilt TDE 3.5.12 (with autotools) on the same computer, and it uses "lib64" as expected. So I guess it doesn't come from an old patch from KDE 3.5.10. Maybe it's related to the cmake porting ?
Le 04/09/2011 19:11, Ilya Chernykh a écrit :
On Sunday 04 September 2011 15:36:44 /dev/ammo42 wrote:
I had the same problem with Slackware64 4 months ago (Slackware64 uses lib64 too): no /opt/kde3/lib64/kde3 libraries were found (but I didn't know strace, so I didn't find the origin of the problem).
I think this is a freedesktop standard. OpenSUSE also uses /usr/lib64 and /opt/kde3/lib64
I've just rebuilt TDE 3.5.12 (with autotools) on the same computer, and it uses "lib64" as expected. So I guess it doesn't come from an old patch from KDE 3.5.10. Maybe it's related to the cmake porting ?
Yes, it could be.
Can you please provide a list of files that are supposed to be installed in lib64/, and are instead installed in lib/?
Thanks!
Tim
Le 04/09/2011 19:11, Ilya Chernykh a écrit :
On Sunday 04 September 2011 15:36:44 /dev/ammo42 wrote:
I had the same problem with Slackware64 4 months ago (Slackware64 uses lib64 too): no /opt/kde3/lib64/kde3 libraries were found (but I didn't know strace, so I didn't find the origin of the problem).
I think this is a freedesktop standard. OpenSUSE also uses /usr/lib64 and /opt/kde3/lib64
I've just rebuilt TDE 3.5.12 (with autotools) on the same computer, and it uses "lib64" as expected. So I guess it doesn't come from an old patch from KDE 3.5.10. Maybe it's related to the cmake porting ?
Did you set -DLIB_SUFFIX="64" ?
I just looked through the CMake files and it appears that if that flag is set (and it is a relatively standard CMake flag if you Google it) that the libraries should be installed into lib64/.
Also make sure that LIB_INSTALL_DIR is not being overridden via a CMake flag anywhere in your build scripts.
Tim
Le 04/09/2011 20:13, Timothy Pearson a écrit :
Did you set -DLIB_SUFFIX="64" ? I just looked through the CMake files and it appears that if that flag is set (and it is a relatively standard CMake flag if you Google it) that the libraries should be installed into lib64/.
Also make sure that LIB_INSTALL_DIR is not being overridden via a CMake flag anywhere in your build scripts.
Hello, Yes I already have -DLIB_SUFFIX="64" . most of my cmake command is auto-generated by rpmbuild macros. I just have to add the optionnal features (-DWITH_XXX=ON) ...
The actual command for configuring kdebase 3.5.13 on RHEL6 is :
/usr/bin/cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX:PATH=/opt/trinity -DCMAKE_INSTALL_LIBDIR:PATH=/opt/trinity/lib64 -DINCLUDE_INSTALL_DIR:PATH=/opt/trinity/include -DLIB_INSTALL_DIR:PATH=/opt/trinity/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/opt/trinity/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DWITH_SASL=ON -DWITH_LDAP=ON -DWITH_SAMBA=ON -DWITH_OPENEXR=ON -DWITH_XCOMPOSITE=ON -DWITH_XCURSOR=ON -DWITH_XFIXES=ON -DWITH_XRANDR=ON -DWITH_XRENDER=ON -DWITH_XDAMAGE=ON -DWITH_XEXT=ON -DWITH_LIBUSB=ON -DWITH_LIBRAW1394=ON -DWITH_PAM=ON -DWITH_SHADOW=OFF -DWITH_XDMCP=ON -DWITH_XINERAMA=ON -DWITH_ARTS=ON -DWITH_I8K=OFF -DWITH_HAL=ON -DBUILD_ALL=ON ..
then after the "make install", libraries are copied to /opt/trinity/lib64 as expected. Alas, kwin (and other kdebase stuffs) still keep looking at /opt/trinity/lib for ".la" files ...
FYI, please note that with TDE 3.5.12 , I get the exact opposite behaviour: If I try to force "/opt/trinity/lib" for the libraries (no problem with lib64). then my ./configure is :
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/opt/trinity --exec-prefix=/opt/trinity --bindir=/opt/trinity/bin --sbindir=/opt/trinity/sbin --sysconfdir=/etc --datadir=/opt/trinity/share --includedir=/opt/trinity/include --libdir=/opt/trinity/lib --libexecdir=/opt/trinity/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-rpath --enable-new-ldflags --disable-dependency-tracking --disable-debug --disable-warnings --enable-final --with-pam=yes --with-kdm-pam=kdm --with-kcp-pam=kcheckpass --with-kss-pam=kscreensaver --with-libraw1394 --with-openexr --with-samba --with-xinerama --with-xscreensaver --without-shadow --with-extra-includes=/opt/trinity/include/tqt
Then after "make install", the libraries are installed under /opt/trinity/lib as expected, BUT this time kwin & co are searching the ".la" files under /opt/trinity/lib64 !!!
To sum up things: TDE 3.5.12 (autotools) only works with /opt/trinity/lib64 TDE 3.5.13 (cmake) only works with /opt/trinity/lib
What an headache ! :-)
Francois Andriot
Le 04/09/2011 20:13, Timothy Pearson a écrit :
Did you set -DLIB_SUFFIX="64" ? I just looked through the CMake files and it appears that if that flag is set (and it is a relatively standard CMake flag if you Google it) that the libraries should be installed into lib64/.
Also make sure that LIB_INSTALL_DIR is not being overridden via a CMake flag anywhere in your build scripts.
Hello, Yes I already have -DLIB_SUFFIX="64" . most of my cmake command is auto-generated by rpmbuild macros. I just have to add the optionnal features (-DWITH_XXX=ON) ...
The actual command for configuring kdebase 3.5.13 on RHEL6 is :
/usr/bin/cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX:PATH=/opt/trinity -DCMAKE_INSTALL_LIBDIR:PATH=/opt/trinity/lib64 -DINCLUDE_INSTALL_DIR:PATH=/opt/trinity/include -DLIB_INSTALL_DIR:PATH=/opt/trinity/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/opt/trinity/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DWITH_SASL=ON -DWITH_LDAP=ON -DWITH_SAMBA=ON -DWITH_OPENEXR=ON -DWITH_XCOMPOSITE=ON -DWITH_XCURSOR=ON -DWITH_XFIXES=ON -DWITH_XRANDR=ON -DWITH_XRENDER=ON -DWITH_XDAMAGE=ON -DWITH_XEXT=ON -DWITH_LIBUSB=ON -DWITH_LIBRAW1394=ON -DWITH_PAM=ON -DWITH_SHADOW=OFF -DWITH_XDMCP=ON -DWITH_XINERAMA=ON -DWITH_ARTS=ON -DWITH_I8K=OFF -DWITH_HAL=ON -DBUILD_ALL=ON ..
then after the "make install", libraries are copied to /opt/trinity/lib64 as expected. Alas, kwin (and other kdebase stuffs) still keep looking at /opt/trinity/lib for ".la" files ...
FYI, please note that with TDE 3.5.12 , I get the exact opposite behaviour: If I try to force "/opt/trinity/lib" for the libraries (no problem with lib64). then my ./configure is :
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/opt/trinity --exec-prefix=/opt/trinity --bindir=/opt/trinity/bin --sbindir=/opt/trinity/sbin --sysconfdir=/etc --datadir=/opt/trinity/share --includedir=/opt/trinity/include --libdir=/opt/trinity/lib --libexecdir=/opt/trinity/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-rpath --enable-new-ldflags --disable-dependency-tracking --disable-debug --disable-warnings --enable-final --with-pam=yes --with-kdm-pam=kdm --with-kcp-pam=kcheckpass --with-kss-pam=kscreensaver --with-libraw1394 --with-openexr --with-samba --with-xinerama --with-xscreensaver --without-shadow --with-extra-includes=/opt/trinity/include/tqt
Then after "make install", the libraries are installed under /opt/trinity/lib as expected, BUT this time kwin & co are searching the ".la" files under /opt/trinity/lib64 !!!
To sum up things: TDE 3.5.12 (autotools) only works with /opt/trinity/lib64 TDE 3.5.13 (cmake) only works with /opt/trinity/lib
What an headache ! :-)
That's odd. Can you attach your strace log for me to look at?
Thanks!
Tim
Le 04/09/2011 20:57, Timothy Pearson a écrit :
That's odd. Can you attach your strace log for me to look at?
Thanks!
Tim
Here is my kwin's strace: tqt, dbus-tqt, kdelibs and kdebase 3.5.13 are all compiled and installed with libdir=/opt/trinity/lib64 (directory /opt/trinity/lib at all) .
Francois Andriot
Le 04/09/2011 20:57, Timothy Pearson a écrit :
That's odd. Can you attach your strace log for me to look at?
Thanks!
Tim
Here is my kwin's strace: tqt, dbus-tqt, kdelibs and kdebase 3.5.13 are all compiled and installed with libdir=/opt/trinity/lib64 (directory /opt/trinity/lib at all) .
Francois Andriot
OK, that helped; I think I found the problem.
Can you apply the attached patch to kdelibs and recompile/reinstall kdelibs, then test again?
If it does not work please attach your config.h file from your build directory.
Thanks!
Tim
Le 04/09/2011 21:35, Timothy Pearson a écrit :
Here is my kwin's strace: tqt, dbus-tqt, kdelibs and kdebase 3.5.13 are all compiled and installed with libdir=/opt/trinity/lib64 (directory /opt/trinity/lib at all) .
OK, that helped; I think I found the problem.
Can you apply the attached patch to kdelibs and recompile/reinstall kdelibs, then test again?
If it does not work please attach your config.h file from your build directory.
Yes, I applied it and it looks like the problem has gone away :-) Thanks a lot for your reactivity !
Francois Andriot
Le 04/09/2011 21:35, Timothy Pearson a écrit :
Here is my kwin's strace: tqt, dbus-tqt, kdelibs and kdebase 3.5.13 are all compiled and installed with libdir=/opt/trinity/lib64 (directory /opt/trinity/lib at all) .
OK, that helped; I think I found the problem.
Can you apply the attached patch to kdelibs and recompile/reinstall kdelibs, then test again?
If it does not work please attach your config.h file from your build directory.
Yes, I applied it and it looks like the problem has gone away :-)
Glad to hear it! The patch is now in SVN as of revision 1251417.
Thanks a lot for your reactivity !
No problem, I am glad I was able to help. :-)
Tim
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
Good thinking! Although as a Debian/Ubuntu developer I could take offence at your comment... ;-)
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.
Thanks!
Tim
Le Sun, 4 Sep 2011 13:03:53 -0500, "Timothy Pearson" kb9vqf@pearsoncomputing.net a écrit :
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
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).
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
<snip>
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).
I know that. :-) I should clarify that even though I build packages for, and use, Ubuntu on a regular basis, I do NOT agree with some of their design decisions. So I am sort of a "rogue" Debian/Ubuntu developer I guess, who would like to see more standardisation in Linux in general.
Tim
-
/dev/ammo42 -
Francois Andriot -
Ilya Chernykh -
Timothy Pearson