-Current build problems with audio/arts: "lt-mcopidl in
free(): error: chunk is already free" and core dumped
pdseniura at techie.com
Fri Aug 6 15:19:30 PDT 2004
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).
The mcopidl being created here should have the most
current pthread that CTM deltas provide, as I have
stated the world & kernel are all freshly built &
installed from less-than-day-old current srcs. Yes I
do the mergemaster/-p cmds at the right times, too. ;)
IF there are other -llibs then both of our logs aren't
showing them probably due to getting the --silent
And IF it turns out that there *are* other -llibs
being linked, and those are in other ports, then they
should hopefully be properly declared on the Makefile's
*_DEPENDS list. There is no other way for portupgrade
to follow a proper chain otherwise.
That's the whole reasoning of the methods I'm using to
recompile everything monolithically with gcc342. After
all is said & done, there _will be *NO* mixups_ (mix
of gcc33- & gcc342-created binaries as you mentioned).
I can write about my methods in a longer msg later.
Just suffice it to say I've been systems programmer
on big-iron mainframes for 27+ years. Having to use
IBM's SMP/E has taught a lot of lessons -- I feel my
logic in how we are keeping track of what portupgrade
is doing is impeccable. We are trusting portupgrade's own logic and not altering it one whit. GLib20 and
libiconv are as up-to-date as CTM will let us, and they
were up-to-date very early-on during this long process,
no commits have updated them _since_ this started, so
everything that uses them should already be getting
good code coming from gcc342.
I will let portupgrade run over the weekend -- as-is,
with crud in mcopidl -- and let most of the KDE pieces
fail. GNome pieces are building just fine. We're
down to less than 90 pkgs now out of 522, most of them
obviously will be KDE-related. We are not suppose to
be coming in over the weekend (no one authorized it), so any CTM deltas will be caught up on Monday sometime.
(I'm still fighting to get CVS working thru our
I really do appreciate your help. I'm more frustrated
at not having any answers to our debacle and thus
wasting a weekend not having KDE ready to use. :(
Thank you again, and have a great weekend.
I'm going home where there are no li'l-endians at all. ;)
-- thx, Paul Seniura.
----- Original Message -----
From: Michael Nottebrock <michaelnottebrock at gmx.net>
Date: Fri, 6 Aug 2004 22:07:08 +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 Friday 06 August 2004 21:37, P.D. Seniura wrote:
> > Hi,
> > rabarber's build logs for audio/arts is showing
> > the very same error msg "chunk is already free".
> Ehm, no, they don't. Perhaps you've been looking at the wrong log or mistook
> one warning for another. The correct log is
> Here is the relevant section:
> if /bin/sh ../../libtool --silent --mode=compile --tag=CXX c++ -DHAVE_CONFIG_H
> -I. -I. -I../.. -I../../flow -I../../flow/gsl -I../../flow -I../../mcop
> -I../.. -I/usr/local/include -I/usr/X11R6/include -I/usr/local/include
> -I../../libltdl -DQT_THREAD_SUPPORT -L/usr/local/lib -I/usr/local/include
> -I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H -D_THREAD_SAFE
> -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith
> -Wwrite-strings -DNDEBUG -DNO_DEBUG -O -pipe -DHAVE_VASPRINTF -fno-exceptions
> -fno-check-new -fno-common -ftemplate-depth-99 -MT datahandle.lo -MD -MP
> -MF ".deps/datahandle.Tpo" -c -o datahandle.lo datahandle.cpp; \
> then mv -f ".deps/datahandle.Tpo" ".deps/datahandle.Plo"; else rm -f
> ".deps/datahandle.Tpo"; exit 1; fi
> /bin/sh ../../libtool --silent --mode=link --tag=CXX c++ -Wnon-virtual-dtor
> -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG
> -DNO_DEBUG -O -pipe -DHAVE_VASPRINTF -fno-exceptions -fno-check-new
> -fno-common -ftemplate-depth-99 -o libgslpp.la datahandle.lo
> -Wl,-export-dynamic -L/usr/local/lib -L/usr/X11R6/lib -ljpeg
> gmake: Leaving directory
> gmake: Entering directory `/tmp/a/ports/audio/arts/work/arts-1.2.3/flow'
> ../mcopidl/mcopidl -t ../flow/artsflow.idl
> ../flow/artsflow.idl: warning: Arts::WaveDataHandle::load (method) collides
> with Arts::WaveDataHandle::load (method)
> if /bin/sh ../libtool --silent --mode=compile --tag=CXX c++ -DHAVE_CONFIG_H
> -I. -I. -I.. -I../mcop -I/usr/local/include -I/usr/X11R6/include
> -I/usr/local/include -I../libltdl -DQT_THREAD_SUPPORT -L/usr/local/lib
> -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H
> -D_THREAD_SAFE -D_REENTRANT -I/usr/local/include/glib-2.0
> -I/usr/local/lib/glib-2.0/include -Wnon-virtual-dtor -Wno-long-long
> -Wundef -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O -pipe
> -DHAVE_VASPRINTF -fno-exceptions -fno-check-new -fno-common
> -ftemplate-depth-99 -MT artsflow.lo -MD -MP -MF ".deps/artsflow.Tpo" -c -o
> artsflow.lo artsflow.cc; \
> > Please when you have a chance go look at its own logs
> > and you'll see it, I have, yes on _that_ site! ;)
> > "chunk is already free" means "double-free" to me.
> > Difference is: rabarber's build isn't crashing,
> > but mine is,
> > on the _very same_ error
> > running the _very same_ binary.
> > I gotta use this puny pentium2 box, tho, and I need
> > to turn on those knobs inside arts' build.
> > The crux of the whole matter, therefore, is in the
> > mcopidl pgm itself, and its srcs are distributed
> > inside the arts project, and it was obviously written
> > that way (double-free).
> > I see this as a KDE problem, but it would seem to be
> > out of our hands for a quick fix.
> It is not a KDE problem as far as I can see and as far as I'm concerned. It is
> far more likely to be a problem of "puny pentium 2", very possibly due to
> pilot error. I can't guess at what's causing it, but it's quite certain to be
> a very local and very special condition.
> I'd start with getting those libmap.conf entries out of your system - -CURRENT
> has been at libpthread long enough now, if you still have stuff linking to
> libc_r, you should get them replaced. I'd also try my suggestion of
> investigating the dependency libraries of mcopidl.
> Please, stop insisting this is a KDE problem. There's is no evidence at all it
> is. The absence of any similar problem reports (and the absence of the
> warning in _any_ buildlogs on fruitsalad) clearly indicate the problem is
> local to _your_ system instead.
> ,_, | 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
Sign-up for Ads Free at Mail.com
More information about the freebsd-ports