Re: [gnugo-devel] Patches for 3.8

[David Denholm]

Gunnar Farnebäck <address@hidden> 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)