On Thursday 03 June 2010 14:14:48 Ken Moffat wrote: > On 3 June 2010 20:11, Trent Shea <[email protected]> wrote: > > Thanks for the heads up. So far I've only run into trouble with libmng > > and cvs (which I haven't investigated.) I believe both packages have not > > had a release in the last 2-3 years. > > I got this patch from fedora. I'd forgotten about cvs - only built it the > once, for development grep. I can't remember the details. Ah, fedora > have it as needed for x86_64 (rhbz#449424) but I don't recall any more > about it beyond 'conflicting types for getline'. > > Probably down to a glibc update, which is why I haven't rushed to put it > in -patches (-dev is still targetting 6.5, where x86_64 isn't necessarily > supported). > > ĸen Thanks, that did the trick. I actually needed cvs for autopoint (part of gettext,) which gets run during autoreconf on another package -fun fun.
I have most of the stuff I normally build done now. I was worried when I started, but pioneers have paved the way and the build was rather painless. There were fPIC issues in libmng, ghostscript, pciutils, and mysql. There's a bug report for mysql http://bugs.mysql.com/bug.php?id=39288, it looks like they'll eventually create a shared library for libmysqld, but for now CFLAGS and CXXFLAGS work. Just a note: mysql builds fine but amarok fails to build against it, complaining about libmysqld.a; pciutils, the same thing but with a KDE package doing the complaining. I had to change the make command for unzip /linux/linux_noasm/ libcap is not in BLFS, but I changed lib=* to lib=lib I'm not really crazy about lib64 -> lib or 64 bit libs in lib; from the bit I've already read I may rebuild with /lib for 32bit and /lib64 for 64bit. This is just thinking out loud, but I can see that udev will need to drop stuff in /lib (if not lib /usr/lib...,) kbd, mandb and probably a hand full of others, too. Any idea what to do with glibc's, and other's, --libexecdir=/usr/lib/glibc.. Ugh, a distro is starting to look appealing; I haven't even had a chance to start watching for security updates etc. Maybe bsdify a bit and use libexec, looks like fedora did, but then what to do with pt_chown when building 32bit glibc, I assume just discard it and keep the 64 bit one, looks like debian did. Oh boy... Oddly enough top reports more memory with the x86_64 build, even when CONFIG_HIGHMEM4G=y is set for the 32 bit kernel free total used free shared buffers cached Mem: 4047840 3964152 83688 0 102704 1920156 free total used free shared buffers cached Mem: 3105576 2111928 993648 0 47980 1714144 Five packages out of 130 or so that needed a little arm twisting to build on x86_64, not too bad. Oh, and none of my browsers open mng files... Gwenview can open some of them. If I try removing libmng it looks like qt and xine-lib uses it. Oh, and a little kick in the face, a bug that was partly responsible for me rebuilding is still on the system, at least this time around I didn't strip everything and the gdb output I have gave me enough info to see there's already a bug report! Anyhow, I threw my install log and package list on pastebin (set to expire in a month.) The dpkg section is pretty rough, I haven't tried building following these instructions, we'll see how they hold up when I try building again ;) and on that note, these 'instructions' are pretty specific to dpkg, but should provide a rough order and package list to get a decent kde-4 system up, if anyone is interested. install_log.txt: http://pastebin.com/U9f5iWpm dpkg -l: http://pastebin.com/YkcvEmfs -- Regards, Trent. -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
