harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib] [build] Unnecessary linking
Date Wed, 02 Jun 2010 11:05:19 GMT

In message <201006021012.o52ACnpm026145@d12av01.megacenter.de.ibm.com>,
"Mark Hindess" writes:
> 
> If you are following the commits, you might have noticed that I am
> trying to fix some of the unnecessary linking in our builds.  Most
> recently I've been looking at the linking of the static library
> hypool.
>
> We link against this static library in almost all of the build files
> in classlib but only hyzip (both versions) and hythr actually use it.
> However, if I remove the unnecessary references to hypool.{a,lib} from
> the build then some instrument tests fail.
> 
> Running the failing test with ld debug like this:
> 
>   cd target/hdk/build/test/instrument
>   LD_DEBUG_OUTPUT=ld.log LD_DEBUG=all \
>     ../../../jdk/jre/bin/java \
>       -cp ../junit.jar:../hamcrest-library.jar:instrument_tests.jar \
>         org.junit.runner.JUnitCore \
>           org.apache.harmony.tests.java.lang.instrument.HelloWorldTest
> 
> reveals the problem[0]:
> 
>   target/hdk/jdk/jre/bin/libhyinstrument.so:
>     error: symbol lookup error: undefined symbol: pool_removeElement (fatal)
> 
> The problem is that while instrument doesn't use hypool.  It does
> statically link hyzip which does use hypool but does not include it.
> Obviously I could just link hyinstrument with hypool again but fixing
> indirect dependencies this way seems kind of ugly.
>
> Fixing it on windows is straightforward as adding a .lib to a .lib
> does the right thing.  But on linux you can't just include hypool.a
> in hyzip.a because it just creates a nested archive so you have to
> un/pack the members.
>
> I'm just running a few more tests before I check in the changes but I
> thought I'd mention it here since the reason for the changes wont be
> entirely obvious from the diff and because the LD_DEBUG trick is quite
> useful for debugging these kind of problems.

I've checked these changes in at r950490.  Testing would be appreciated.

Regards,
 Mark.

> [0] Find the correct log for the child process, jump to the end and search
>     back for "fatal".



Mime
View raw message