-Current build problems with audio/arts: "lt-mcopidl in free(): error: chunk is already free" and core dumped

P.D. Seniura pdseniura at techie.com
Mon Aug 9 14:12:50 PDT 2004


Hi again,


----- Original Message -----
From: Michael Nottebrock <michaelnottebrock at gmx.net>
Date: Sat, 7 Aug 2004 00:34:16 +0200
To: "P.D. Seniura" <pdseniura at techie.com>
Subject: Re: -Current build problems with audio/arts: "lt-mcopidl in free(): error: chunk is already free" and core dumped

> On Saturday 07 August 2004 00:19, P.D. Seniura wrote:
> > Hi again,
> >
> > I guess I will be doing some serious hacking.
> > The --silent option on the libtool --mode=link cmd may
> > be keeping several things hidden.  The only -llib shown
> > is -lpthread.  I have _nothing_ in /etc/libmap.conf
> > to override pthread.  In fact _everything else_ is
> > being made to point _to_ pthread.  That info comes
> > from the msg-thread I mentioned earlier in this
> > discussion (and previously showed my libmap.conf).
> 
> Yes, and I'm suggesting to turn that off so can find and eliminate any 
> remaining libraries linked to the wrong threads libs. libmap is a great 
> feature, but not completely failsafe.

I'm sure I tried that last week & mentioned it, anyhow
I tried it again today and did not help.  I even set
LD_LIBMAP_DISABLE=1 in /etc/make.conf and in current
shell environment, no help.  I built a kernel with
all the debug & witness tests, no help to figure out
where this is dying.

I said I'd need to be doin' some hackin'.  ;)
Firstly I got the freebsd port skeleton makefile to
add another sed string to strip out --silent, so we
can now see what it's doing.  The -llibs on the
--mode=link cmds I then checked the installed libs with
ldd -- they are all freshly built with gcc342 and have
no mish-mash of threadlib anomalies etc. 
Then I wanted to see how mcopidl is created. 
The ldd util said mcopidl, that Makefiles are pointed
to _during building_, is not dynamic.  Okay there is
a version of mcopidl under the .libs subdir that _is_
dynamic; there is also a .libs/lt-mcopidl which has
a link to the subdir versions of arts's other libs
(instead of /usr/local/lib which plain .libs/mcopidl
is linked to when 'installed').  So first thing was
to hack the Makefiles and let it run .libs/lt-mcopidl
for those translations.  Getting closer, but it still
does abort/dump.  Next trick was to find some way to
run lt-mcopidl by hand so gmake can be tricked to
think it was done already, then just continue on. 
The way to trick it I finally used gdb to run the same
cmd cd'ing to where gmake would've been, then 'run' followed by the gmake parms for mcopidl, let gdb handle
the trap, say 'cont' to let gdb/mcopidl finish.  Another part of the trick is to make sure no mcopidl-generated output files are there, let
gdb/mcopidl create them 'new', then gdb 'cont' & 'quit'
will close 'em up proper.  That was enough to let gmake
see that we had already done the mcopidl steps for each
of those modules.  Don't let portupgrade do any
cleaning, and it'll find out where to continue in the
gmake steps for arts, and it'll finally install.

BTW gdb said no debug symbols in the mcopidl being
created during building, so we couldn't see where
the double-free was occurring.  gdb did say the
kill() was coming from /lib/libc.so.5 to abort it. 
Nothing else useful.

The ldd util shows no mixups of thread libs at all,
from any of these modules, even under work subdirs. 
The installed files point to /lib/libc.so.5, /usr/lib,
& /usr/local/lib (-ljpeg -lpthread etc.), _those_ libs
have already been built in days past with gcc342, all
clean, no thread-lib mixups, etc. etc. etc.  I've been
saying how careful I've been thru this rebuild process. ;)

This lets me continue with portupgrad'ing what is
left over so far. 
_But_ now kdelibs needs to run mcopidl that was just
installed, and yep it is still aborting/dumping.

And so that brings me to a question about these
packages being built on the build-farms -- the logs
at rabarber shows being linked against /usr/local/lib
on _that_ machine -- is /usr/local/lib on _that_
machine a fresh build of a 5-current world?  It just
seems right now the main difference is: rabarber does
not use a current world, while I am of course.  I'm
about to take this to the -current@ maillist, since we
may have some kind of glitch needing their expertise.

This was rushed, and having to use their html editor,
sorry for the ugliness.

Thank you again (and anyone else) for your time.


>    ,_,   | Michael Nottebrock               | lofi at freebsd.org
>  (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
>    \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org


  --  thx, Paul Seniura.


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm




More information about the freebsd-ports mailing list