Re: dico FTBFS on mips/mipsel -- RFH
On Thu, 2014-09-25 at 20:00 +0300, أحمد المحمودي wrote:
> On Thu, Sep 25, 2014 at 02:51:42PM +0000, James Cowgill wrote:
> > I've had a small look at this (I don't have much at the moment).
> >
> > When you run your example with LD_DEBUG=libs, you get the error:
> > /usr/lib/mips-linux-gnu/libgc.so.1: error: symbol lookup error: undefined symbol: __data_start (fatal)
> >
> > The Boehm GC headers (on some arches) indicate that the calling program
> > is expected to define __data_start somewhere (presumably by gcc) and
> > this isn't happening.
I've now tracked down the cause of this bug.
Since 2.0, guile started depending on the Boehm GC. The GC needs to know
where the start of the main data section is and on most linux based
architectures it will scan the memory backwards from a known location to
find it. On MIPS (and some other arches) it uses the symbol __data_start
instead. This symbol is always defined by crt1.o so usually isn't a
problem, however if this symbol is not used by any of the objects passed
to ld, ld will not add the symbol to the dynamic symbols table. This
will then cause dlopen(guile.so) to fail at runtime since __data_start
is not defined.
This is probably a bug in libgc unless there's a good reason to use
__data_start on mips (I'm not sure why it's used). You can workaround
this by passing "-Wl,-E" to the link stage of dico (and any executable
which could load guile.so) to force __data_start to be exported. The
build failure on s390x also seems to be this problem.
James
Reply to: