The kdebase build failed within a few minutes. I'm attaching a log.
Nothing compiled. Only the end message that configure was done and that's all.
arts and kdelibs from svn are installed.
I would think that if kdelibs did not compile correctly I would see some kind of error message, but I see nothing. I am not using any -j flags with the make command. I'm inclined to think something is awry with the makefiles, but I'm guessing.
The odd thing is after configure completes the next command in the build script is:
make || exit 1
Yet the build script tries to continue as though make exited without errors.
Here is the affected portion of the build script:
================================================== CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --sysconfdir=${SYSCONFDIR} \ --libdir=${LIBDIR} \ --with-ssl-dir=${PREFIX} \ --with-shadow \ --disable-debug \ --disable-dnssd \ --program-prefix="" \ --program-suffix="" \ --build=$TARGET-slackware-linux
make || exit 1 ==================================================
Weird. Quite weird!
Some messages I noticed:
================================================== acinclude.m4:6591: warning: underquoted definition of _LT_AC_TRY_LINK ================================================== unknown icon type in kate/pics/Makefile.in (sessionchooser.png) ================================================== checking linux/cdrom.h usability... no checking linux/cdrom.h presence... yes configure: WARNING: linux/cdrom.h: present but cannot be compiled configure: WARNING: linux/cdrom.h: check for missing prerequisite headers? configure: WARNING: linux/cdrom.h: see the Autoconf documentation configure: WARNING: linux/cdrom.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/cdrom.h: proceeding with the preprocessor's result configure: WARNING: linux/cdrom.h: in the future, the compiler will take precedence checking for linux/cdrom.h... yes ==================================================
A header file exists at /usr/include/linux/cdrom.h
I am using 2.6.27.48 but I leave the original 2.6.27.7 headers installed because that is what the Slackware 12.2 release was compiled against. I never have had a problem before with kernel headers.
Darrell
The kdebase build failed within a few minutes. I'm attaching a log.
Nothing compiled. Only the end message that configure was done and that's all.
arts and kdelibs from svn are installed.
I would think that if kdelibs did not compile correctly I would see some kind of error message, but I see nothing. I am not using any -j flags with the make command. I'm inclined to think something is awry with the makefiles, but I'm guessing.
The odd thing is after configure completes the next command in the build script is:
make || exit 1
Yet the build script tries to continue as though make exited without errors.
Here is the affected portion of the build script:
================================================== CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --sysconfdir=${SYSCONFDIR} \ --libdir=${LIBDIR} \ --with-ssl-dir=${PREFIX} \ --with-shadow \ --disable-debug \ --disable-dnssd \ --program-prefix="" \ --program-suffix="" \ --build=$TARGET-slackware-linux
make || exit 1
Weird. Quite weird!
Some messages I noticed:
================================================== acinclude.m4:6591: warning: underquoted definition of _LT_AC_TRY_LINK ================================================== unknown icon type in kate/pics/Makefile.in (sessionchooser.png) ================================================== checking linux/cdrom.h usability... no checking linux/cdrom.h presence... yes configure: WARNING: linux/cdrom.h: present but cannot be compiled configure: WARNING: linux/cdrom.h: check for missing prerequisite headers? configure: WARNING: linux/cdrom.h: see the Autoconf documentation configure: WARNING: linux/cdrom.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/cdrom.h: proceeding with the preprocessor's result configure: WARNING: linux/cdrom.h: in the future, the compiler will take precedence checking for linux/cdrom.h... yes ==================================================
A header file exists at /usr/include/linux/cdrom.h
I am using 2.6.27.48 but I leave the original 2.6.27.7 headers installed because that is what the Slackware 12.2 release was compiled against. I never have had a problem before with kernel headers.
Darrell
I've never seen that before! Can you send over a complete copy of the entire build script? I want to make sure no BASH-ish mistakes were made. Thanks!
Tim
I've never seen that before! Can you send over a complete copy of the entire build script? I want to make sure no BASH-ish mistakes were made.
I never have seen this before either.
Interestingly, the problem disappeared. In short, in hindsight, yesterday was "one of those days." Let me humor you a bit. :)
Yesterday I updated some routine Slackware package updates. The usual patched files for security reasons. I paid little attention that three of the updated packages were xserver.
I noticed some odd behavior as the day progressed but thought little about that. My computer was a busy multitasking beaver yesterday. Thus, I presumed the primary cause was I had many tasks running that battled for CPU and video time. I also had been experimenting with the preload daemon and presumed that was part of the problem. I disabled the daemon and continued.
While I ran the builds in the virtual machine in the background, I also was experimenting with a newer conky release. I was trying to add warning colors to various sensor values. I was having a devil of a time getting that to work.
After the umpteenth time of seeing the quirky behavior with the kdebase build, I gave up for the day. I powered on my HTPC to watch a movie recording. In that box I use the same Slackware 12.2 configuration. I had updated all of my machines with the latest patches.
I use XBMC as my front-end. I immediately received an error message about XBMC needing some glx-something-or-other support.
I concluded quickly the xserver security updates had done something.
I returned to my office machine and restored the original xserver packages. I restarted X and still could not run glxgears. Classic WTF.
I reinstalled the mesa and nvidia packages and rebooted.
All problems disappeared. I then reinstalled the updated xserver packages and repeated reinstalling the mesa and nvidia packages. I rebooted rather than restarting X.
No more problems. I repeated the exercise with my HTPC. I again could start XBMC.
Grumble, grumble. Make a PBJ sandwich to calm the nerves.
Initially I concluded the conky issues were related to the xserver patches. Today I decided the problems are syntax issues in the config file, but I'm not totally convinced.
Somewhere in between all of this, late last night, on a whim, during my last attempt to build kdebase, I bumped the memory for my virtual machine from 512 MB to 768 MB. The build failed again, but I had not yet discovered the problem with XBMC and the xserver patches. I fixed the patch issues after bumping the memory.
This morning I decided to try running the build script and terminating the script before the make command.
Then I manually ran the make command. The danged thing started compiling.
Curious, I restored the build script to my previous condition. The build script again tried to compile.
I have no idea to the actual cause of the original reported problem. Could have been a lack of memory in the virtual machine. Could have been the quirky behavior in X after updating the security patches. Or a combination of both.
At this point all seems to be working again. I lack the motivation or energy to troubleshoot in any meticulous manner. Problem resolved and who cares about the root cause.
Anybody who works with computers in any detail as we do has had days like this. :) There is a reason a particular bumper sticker is popular.
Back to the task at hand. The kdebase build fails quickly. I'll send a log in another email.