[MKSearch-dev] Week 4 round up

[Phil Shaw]

On 12 Nov 2004, at 11:46, Bruno Postle wrote:

> ..it should probably be this:
> 
>   mkdir -p $mk_build/jaxp

Yes, I quickly discovered this too and applied the change to each of 
the scripts.

> The new test-environment.sh script does the job perfectly.

Thanks. It's handy having it stand alone, though it will be a little 
repetitive with the chained scripts. I wonder if it should be silent 
unless it fails.


> >> I get an error trying to compile jspider, this error is actually
> >> generated by util/list-jspider.sh:
> 
> This is ok now.  In fact everything in the bin/ directory now builds
> properly though there is a typo at the top of compile-jaxp.sh:
> 
>   * the parser class implementations.

Ah thanks, corrected that.


> > This problem may originate from the runtime environment, hence the
> > shared object references: *.so.4.0.0. I presume the 4.0.0 reference
> > indicates your version of GCJ. I'm using version 3.3.3.
> 
> No the /usr/lib/libgcj.so.4.0.0 file is actually part of 
> libgcj-3.3.2.  The '.so.4.0.0' numbering system is libtool's and
> allows multiple versions of a library to co-exist on a linux system,
> you can read all the gory details here:
> 
>   http://www.gnu.org/software/libtool/manual.html#SEC34

Oh my! I'll save that for a rainy day ;-) Without looking at the 
details, there's a possibility that your runtime classpath may be out 
of step with the compiler classpath. Leave it for now and I'll see if 
I get the same problems on my system.


> > There shouldn't be incompatibilities, but the GNU Java tools are
> > work in progress. Could you try making the JARs afresh on your own
> > system? 
> I get the same error, both with html files in the current directory
> and when using absolute paths.

Okay, I'll take a look at this again next week.

> Presumably the problem is caused by file-handling and wouldn't be a
> problem when the library is used directly?

Fingers crossed it is.

Cheers,

Phil