On Sun, 2009-03-15 at 19:16 +0000, Geoffrey Clements wrote: > On Thursday 12 Mar 2009, Geoffrey Clements wrote: > > On Thursday 12 Mar 2009, Francesco Romani wrote: > > > On Thu, 2009-03-12 at 15:33 +0000, Geoffrey Clements wrote: > > > > I recently upgraded my PC from an x86 to an x86_64 X 4 architecture and > > > > well used transcode recipes started segfaulting. > > > > > > > > After a bit of investigation I found that it is the "-j t,l,b,r" switch > > > > that's causing the problem; the segfault occurs if t <> b or l <> r. > > > > > > Hi, > > > > > > thanks for the report. Please file a bug here: > > > http://developer.berlios.de/bugs/?group_id=10094 > > > for tracking purposes. > > > > I'm attempting to get more information with gdb first so that I can file a > > complete bug report, however using code from: > > svn://svn.berlios.de/tcforge/transcode/trunk > > which I think is version 1.1.1 > > > > I've been trying to get transcode to build but no luck. I've got > release-1_1_1 > from mercurial but:
Not quite, but you're near :) You've to switch to the right branch `transcode-1_1' by doing: hg update transcode-1_1 inside your mercurial checkout directory. Beside that, you've discovered an actual bug into current default (main) branch which I'm going to fix. [...] > Yup there they are (the first two undefined ones belong to cfgfile.o), then > why is the linker not finding them? > > I'm sure I'm missing something obvious. Full explanation follows. transcode uses quite a bit internal libraries. Those libraries are private, for internal usage only, and generally speaking aren't useful outside transcode (that can change into far future, however). So, we build them as static and we don't install them. The transcode's build system just install binaries, plugins (and shared, arch-independent data). Enter the linker. When the (static) linker build an executable, it processes the shipped libraries once (... AFAIK), and in supply order. Moreover, it optimizes the binary not including into it any object file unreferenced anywhere. So we face a potential problem. If a library (say, libA) is specified BEFORE another (say, libB), but libB depends on libA, it is possible that a needed object will not end into final executable. That happens because the dependency library is processed BEFORE the dependendant one. That's the issue we're facing. strl* functions aren't used into the libtc's functions (contained into object files) referenced by test-tcmodule.c, nor by test-tcmodule.c directly. So they aren't included into the executable. Then libtcutil is gone, and libtcmodule, which needs further objects, goes out of luck. In theory. In practice, I routinely build transcode at various stage of development, and I can't reproduce this issue. And that puzzles me. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge