Make problem causing gnu-java-beans.lo to be created incorrectly

[Terry Laurenzo]

Actually, I'm sorry for wasting your time thinking about this.  I just
rebuilt from scratch and it all worked.  Something must have gotten
screwed up on my end while I was hacking on the project.  I'm building
on a much faster machine now, so I'm not quite as scared to start from
ground zero in the build process.  :)


Thanks for the response.
TJ

On 20 Aug 2005 17:43:36 -0600, Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "Terry" == Terry Laurenzo <tlaurenzo@gmail.com> writes:
> 
> Terry> I also ran into a problem with the sequence of the build. During the
> Terry> first pass build, the gnu-java-beans.lo file is generated prior to the
> Terry> most of its classfiles being compiled.
> 
> At one point we were hitting a libtool bug where, if the last file
> name passed to libtool had a '$' in it, that file could be left out of
> the build.  We fixed this on the 4.0 branch with a hack, but never
> applied this same hack to the trunk...
> 
> Terry> I ran into this while creating a libgcj.dll for MinGW, working
> Terry> off of the 4.1 (May 15, 2005) sources.
> 
> ... but the bug was fixed as a side effect of the big build
> reorganization that happened due to the "big classpath merge".  The
> ChangeLog entry for this is from 2005-07-15 -- so you wouldn't have
> it.
> 
> I would recommend updating to cvs head.  But if you don't want to do
> that, the workaround from the 4.0 branch was to sort the class names,
> e.g.:
> 
>         $(LTGCJCOMPILE) -findirect-dispatch -c -o gnu-java-beans.lo \
>                 `find gnu/java/beans -name '*.class' -print | sort -r`
> 
> This treatment must be applied in all the rules like this that do a
> 'find'.
> 
> BTW I'm just guessing at what the problem might be.  This was a known
> one.  It could be something else entirely...
> 
> Tom
>