Date: Fri, 06 Aug 2004 17:19:27 -0500 From: "P.D. Seniura" <pdseniura@techie.com> To: "Michael Nottebrock" <michaelnottebrock@gmx.net> Cc: freebsd-ports@freebsd.org Subject: Re: -Current build problems with audio/arts: "lt-mcopidl in free(): error: chunk is already free" and core dumped Message-ID: <20040806221927.92A42790037@ws1-14.us4.outblaze.com>
next in thread | raw e-mail | index | archive | help
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). 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 treatment. 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 political firewall.) 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@gmx.net> Date: Fri, 6 Aug 2004 22:07:08 +0200 To: "P.D. Seniura" <pdseniura@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 > http://rabarber.fruitsalad.org/logs/3.2.3-debbie-beta-2/5-CURRENT/arts-1.2.3,1.log > > 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 > -L/usr/X11R6/lib > gmake[3]: Leaving directory > `/tmp/a/ports/audio/arts/work/arts-1.2.3/flow/gslpp' > gmake[3]: 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@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 http://promo.mail.com/adsfreejump.htm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040806221927.92A42790037>