On Thu, 2014-09-25 at 19:10 +1000, Aníbal Monsalve Salazar wrote: > On Thu, 2014-09-18 15:14:53 +0200, Marc Dequènes (Duck) wrote: > > Coin, > > > > Dico's testsuite fails when testing its guile module, which cannot be > > loaded. > > > > When built without cleanup it can be reproduced using: > > ./dicod/dicod --config modules/guile/tests/dicod.conf --stderr -i > > > > We made straces (attached) of the load on mipsel and amd64 and saw strange > > differences at some point. It starts loading the dico guile module which > > drags its linkdeps, loading libguile-2.0.so.22 and a few others until it > > reaches libm.so.6. Then after the second mmap, which succeed, on mipsel it > > starts munmapping many blocks and then strangely try to reload the dico > > guile module again (which fails because the in-place build path is not known > > anymore). I attached the guile.la file containing the linking command. > > > > Could someone help us find out what's going on?
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. James
