[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Patches for 3.8

From: David Denholm
Subject: Re: [gnugo-devel] Patches for 3.8
Date: 23 Dec 2008 21:01:15 +0000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

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/ 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.
>  >
>  >
> 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

Dave Denholm  (still lurking)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]