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
