Gunnar Farnebäck <[email protected]> writes:
> Daniel Bump wrote:
> >> The following patch allows me to compile on OSX. This is not a correct
> >> fix, since patterns/Makefile.in is an autogenerated file (by automake).
> >
> > The following patch seems to be OK. At least after this
> > I can build on both OS/X and Ubuntu.
> >
> > http://sporadic.stanford.edu/bump/gnugo/patches/gnugo-3.8/osx_build_8.1
>
> It looks a bit weird to both have engine/globals.c as a source file
> and link with libengine.a which contains globals.c. On the other hand
> the solution used with extract_fuseki_LDADD, where libengine.a is
> listed twice, isn't all that nice either. Is there anyone on the list
> who is expert enough to say what's the best way to handle link order
> resolution or how to structure the code to avoid these complications?
>
I can't see it's the best way, but another way to force the linker
to bring in a module from a static library is to force a dependency
on a symbol.
Eg if you really want to bring in symbol foo from libengine.a,
you can do something like
gcc -u foo ... libengine.a ...
and the linker adds 'foo' to the list of symbols it needs to
resolve. So when it finds a definition in libengine.a it will bring
in the module defining it, and presumably anything else that can
satisfy any resulting definitions. I suppose an equivalent, and
perhaps more portable, way would be to add a gratuitous reference
to 'foo' from the main program.
I'm sure I stumbled on a linker option which traced the activity,
showing why each module was being loaded. But I can't see it
now - maybe it was a toolset other than gnu.
I did notice while looking through the info for gnu ld that
you can group archives... so
ld ... '-(' libx.a liby.a libz.a '-)'
will repeatedly visit all three until it has run out of
symbols it can resolve. I guess this is equivalent to listing
libengine and libpatterns twice in expand_fuseki
I couldn't get a link error if I removed the duplicate mentions,
though :
$ gcc --version
gcc (Debian 4.3.2-1) 4.3.2
dd
--
Dave Denholm (still lurking)
_______________________________________________
gnugo-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnugo-devel
