OK, same error, so I guess the -j4 flag was not the culprit.
I'll look further into it as I have time.
I tweaked my virtual machine and tried again to build kdebase. Attached is a log.
I did not use any -j process flags. Here are the header includes in my local menutab_impl.h:
========================================== #ifndef __menutab_impl_h__ #define __menutab_impl_h__
#include <stdlib.h> #include <tqlistview.h> #include <kpushbutton.h>
#include "menutab.h" ==========================================
As the last recommended change was to add include '<stdlib.h>' to menutab_impl.h, hopefully the build failing with an error in menutab_impl.cpp is easy to solve. The best I can gather is that MenuTab::connect hasn't been defined, but I don't know how to repair.
OK, same error, so I guess the -j4 flag was not the culprit.
I'll look further into it as I have time.
I tweaked my virtual machine and tried again to build kdebase. Attached is a log.
I did not use any -j process flags. Here are the header includes in my local menutab_impl.h:
========================================== #ifndef __menutab_impl_h__ #define __menutab_impl_h__
#include <stdlib.h> #include <tqlistview.h> #include <kpushbutton.h>
#include "menutab.h"
As the last recommended change was to add include '<stdlib.h>' to menutab_impl.h, hopefully the build failing with an error in menutab_impl.cpp is easy to solve. The best I can gather is that MenuTab::connect hasn't been defined, but I don't know how to repair.
I'm not sure myself, which is why I have not gotten back to you yet. (I've been completely swamped here with work). Hopefully I'll have more time to look into the issue in the coming week.
Tim
FYI
I don't know which team first found and assembled all of these KDE patches. The base patch sets seem to be identical for both teams. The chakra collection provides patches for common third-party KDE apps.
Here are links to the collection of patches:
http://www.chakra-project.org/svn/branches/kde3/
http://vectorlinux.osuosl.org/veclinux-6.0/source/extra/kde/3.5.10/
There are many useful patches available in this collection.
I randomly compared some of the patches to the trinity svn source code. Of those few I compared, seems the patch had not been implemented.
These collections are small gold mines.
The dates in some of the diff files indicate the patches have been available a long time. For whatever reason they never were merged into the KDE source code.
This post serves only as a helpful place holder to find those patches at some future date.
Darrell
FYI
I don't know which team first found and assembled all of these KDE patches. The base patch sets seem to be identical for both teams. The chakra collection provides patches for common third-party KDE apps.
Here are links to the collection of patches:
http://www.chakra-project.org/svn/branches/kde3/
http://vectorlinux.osuosl.org/veclinux-6.0/source/extra/kde/3.5.10/
There are many useful patches available in this collection.
I randomly compared some of the patches to the trinity svn source code. Of those few I compared, seems the patch had not been implemented.
A lot of the patches are already in Trinity; in fact with a couple of exceptions I only started to see significant unpatched files in kdebase.
I will see how far I get with incorporating those patches before the 3.5.12 feature freeze...thanks for letting me know about them!
These collections are small gold mines.
Yes they are. ;-)
The dates in some of the diff files indicate the patches have been available a long time. For whatever reason they never were merged into the KDE source code.
Remember "KDE3 is dead, no more feature patches will be accepted"? That was occurring for a long time before KDE4 actually came out.
This post serves only as a helpful place holder to find those patches at some future date.
By the way, I think I *might* have fixed your kdebase build problem. Can you update kdebase to SVN revision 1172412 or higher and try building kdebase again?
Thanks!
Tim
A lot of the patches are already in Trinity; in fact with a couple of exceptions I only started to see significant unpatched files in kdebase.
Yes, I did sample from that package tree. :)
I will see how far I get with incorporating those patches before the 3.5.12 feature freeze...thanks for letting me know about them!
I am willing to provide grunt work to merge the patches. I can merge the patches with the stock 3.5.10 sources. Thereafter I need ideas how to _efficiently_ compare those patched sources to trinity sources.
Even if many of the patches have already been merged, would be nice to check each patch anyway. At least to create a cross-reference note in the sources or build scripts which trinity svn incorporated the patch. I have been adding notes in my Slackware build scripts so users will know where an original Slackware patch was committed to trinity svn. That provides a simple mechanism of traceability and will help avoid the same repeated questions of what happened to the original patches.
Please let me know.
Remember "KDE3 is dead, no more feature patches will be accepted"? That was occurring for a long time before KDE4 actually came out.
I did not realize the KDE devs had gone anal that early. Just another reason why I have lost lots of respect for the KDE devs over the past several years. A talented bunch, but clueless about human relations and end-users. A very myopic bunch.
By the way, I think I *might* have fixed your kdebase build problem. Can you update kdebase to SVN revision 1172412 or higher and try building kdebase again?
I'll update my local tree. I have 1172360.
I'm still stumped why I can't build outside the virtual machine. I am going to install a fresh copy of 12.2 on a separate partition and start from scratch. I hope that I can discover the reason. The VM works but is too slow.
I don't understand how automake and make files work so my troubleshooting attempts are meager at best. The configure.logs for both environments are identical except for host names and dates. Directories are almost identical. Installed packages are identical. The custom kernels are slightly different, but I don't see why that would make a difference. All I know is that outside the virtual machine the configure process will always fail with the ldd statement I noted in a previous message. Just frustrating and exhausting.
A lot of the patches are already in Trinity; in fact with a couple of exceptions I only started to see significant unpatched files in kdebase.
Yes, I did sample from that package tree. :)
I will see how far I get with incorporating those patches before the 3.5.12 feature freeze...thanks for letting me know about them!
I am willing to provide grunt work to merge the patches. I can merge the patches with the stock 3.5.10 sources. Thereafter I need ideas how to _efficiently_ compare those patched sources to trinity sources.
There really is no way to do that...Trinity has come very far since 3.5.10, and a lot of code has been rewritten/moved/added. I am merging the patches in as I write this; I have to preselect which patches can be safely applied versus those which would be adding duplicate functionality or causing accidental regressions.
Even if many of the patches have already been merged, would be nice to check each patch anyway. At least to create a cross-reference note in the sources or build scripts which trinity svn incorporated the patch. I have been adding notes in my Slackware build scripts so users will know where an original Slackware patch was committed to trinity svn. That provides a simple mechanism of traceability and will help avoid the same repeated questions of what happened to the original patches.
That you could definitely help with as I do not have the time nor inclination to do so. I would suggest pulling each patch file, and comparing it against the current Trinity sources. If it looks like a patch was not applied, look around a bit in the source file to see if the same functionality was implemented in a different manner. If it looks like something is completely missing, please let me know. Also please note that distro-specific patches cannot be applied for obvious reasons--I noticed quite a few of them in kdebase. ;-).
<snip>
I'm still stumped why I can't build outside the virtual machine. I am going to install a fresh copy of 12.2 on a separate partition and start from scratch. I hope that I can discover the reason. The VM works but is too slow.
Not sure; I wouldn't spend too much time on it myself. One idea is that /dev and /proc may need to be mounted in the chroot environment, but that is just a wild guess.
Tim
There really is no way to do that...Trinity has come very far since 3.5.10, and a lot of code has been rewritten/moved/added. I am merging the patches in as I write this; I have to preselect which patches can be safely applied versus those which would be adding duplicate functionality or causing accidental regressions.
I suspected there was no easy way.
That you could definitely help with as I do not have the time nor inclination to do so. I would suggest pulling each patch file, and comparing it against the current Trinity sources. If it looks like a patch was not applied, look around a bit in the source file to see if the same functionality was implemented in a different manner. If it looks like something is completely missing, please let me know.
I'll browse through each patch and do my best. If I'm unsure I'll just send you a note and let you decide.
Also please note that distro-specific patches cannot be applied for obvious reasons--I noticed quite a few of them in kdebase. ;-).
I saw one patch I knew would not get accepted by Debian folks. The one that sources environment variable files from etc/profile.d. As far as I can tell, using /etc/profile.d in Debian is some kind of sacrilege. :) I don' think that particular patch is necessary anyway, at least not in Slackware. Maybe the patch had some value in the Chakra project.
I will see how far I get with incorporating those patches before the 3.5.12 feature freeze...thanks for letting me know about them!
All patches are now in SVN and undergoing a rebuild test. Looks like they will fix a few niggling bugs that have been annoying some of the Trinity Debian testers...thanks again!
Tim
The startkde shell script still references 3.5.10 and should reflect the correct build version. For my package names, in my build scripts I pull the version number from kdelibs/kdecore/kdeversion.h.
The same approach could be used to update startkde on-the-fly when building kdebase. I can run that correction here, but I think the correction should be made by the build process so as to help any person building the package for any distro.
Darrell
-
Darrell Anderson -
Timothy Pearson