Gunnar Farnebäck wrote: > Dan wrote: > > With i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465) > > I get the same error message as with gnugo-3.7.12: > > > > gcc -g -O2 -o mkmcpat mkmcpat.o ../engine/libengine.a ../sgf/libsgf.a > > ../utils/libutils.a ../engine/libengine.a -lncurses > > Undefined symbols: > > "_potential_moves", referenced from: > > _potential_moves$non_lazy_ptr in libengine.a(montecarlo.o) > > ld: symbol(s) not found > > Weird. We only have "potential_moves" in the source. The leading > underscore and the "$non_lazy_ptr" suffix is something the compiler > has invented itself. What does it try to achieve and why does that > mess up a build that at least works with gcc? Does anybody know what's > going on here and are we doing something wrong that gcc happens to be > forgiving about?
Googled a bit ... http://software.intel.com/en-us/articles/intelr-fortran-compiler-for-mac-os-non_lazy_ptr-unresolved-references-from-linking (http://tinyurl.com/8tzjyl) suggests passing -c to libtool or ranlib. (so this might work: RANLIB='ranlib -c' ./configure; make) http://trac.macports.org/ticket/12994 suggests unsetting LD_PREBIND and LD_PREBIND_OVERLAP. Prebinding seems to be an optimization meant for speeding up dynamic linking. Other projects had trouble with that on MacOS X 10.5 as well. The closest I've found to a technical description so far is http://stackoverflow.com/questions/79054/osx-105-leopard-symbol-mangling-with-nonlazyptr (http://tinyurl.com/a8bsep) HTH, Bertram _______________________________________________ gnugo-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnugo-devel
