Was Re: libmng-1.0.10 - x86_64 looking good, and misc.

Trent Shea trentshea at gmail.com
Sun Jun 6 18:54:36 PDT 2010

On Thursday 03 June 2010 14:14:48 Ken Moffat wrote:
> On 3 June 2010 20:11, Trent Shea <trentshea at gmail.com> 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

             total       used       free     shared    buffers     cached
Mem:       4047840    3964152      83688          0     102704    1920156

             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.


dpkg -l:


More information about the lfs-chat mailing list