Date: Mon, 09 Aug 2004 16:12:46 -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: <20040809211246.11B7B790034@ws1-14.us4.outblaze.com>
next in thread | raw e-mail | index | archive | help
Hi again, ----- Original Message ----- From: Michael Nottebrock <michaelnottebrock@gmx.net> Date: Sat, 7 Aug 2004 00:34:16 +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 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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040809211246.11B7B790034>