Hi again... Here's a the few things I've noticed afterwards while doing CBLFS... ...the configure error in kde3-libs-3.5.10 was due (in part) to autoconf-2.64 which had dropped the AH_CHECK_HEADERS macro. This macro was reinstated in autoconf-2.65...perhaps this target should be incremented to 2.65 in <subject> book?
..much later on in CBLFS @ Network-Manager.8.0 the link to the patch does not exist. This much isn't so bad...(I reworked the existing patch to suit)...what *is* troublesome is that Network-Manager.8.0 has a dependency for gudev-1.0 ; afaict the gudev library only appeared in Udev-1.51 and greater, so one would either need to drop back to the Network-Manager.7.x tarball...or...the udev version incremented in the <subject> book. The latter approach is problematic -- you need glib-2 (and g-object) installed to satisfy udev's deps to allow gudev library to build....anyone figured out a plan of attack here?? I've blown it all away and will start from scratch again..(I'd like to put any ideas here to test during the pending rebuild)... *CBLFS* -- if, for whatever reason, you follow the book and install qt3 in /usr and qt4 in /opt, as part of the KDE4 build process you need to compile Automoc4 -- this package will search $PATH looking for qmake and of course the first one it finds will be /usr/bin/qmake.... ..not /opt/qt4/bin/qmake as required... There's likely a work-around for that, but my query here regards KDE4 versus KDE3 -- when do we consider qt4/kde4 'mainstream' enough so as to deprecate qt3/kde3 in CBLFS?....ie; qt4/kde4 in /usr and qt3/kde3 in /opt? Just curious... Any advice on the udev (gudev) stuff greatly appreciated. Cheers! _________________________________________________________________ If It Exists, You'll Find it on SEEK. Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/ _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
