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

Reply via email to