classpath/41699 On Fedora 11 PowerPC IcedTea 7 Build

[mvfranz]

I have hit this bug.  Is there anyway to work around it during the build process?

http://www.mail-archive.com/bug-classpath@.../msg06349.html

[gnu_andrew]

2009/11/7 Michael Franz <mvfranz@...>:
> I have hit this bug.  Is there anyway to work around it during the build
> process?
>
> http://www.mail-archive.com/bug-classpath@.../msg06349.html
>
>

There already is a workaround.  If you check your build logs, you
should notice that the IcedTea build already downloads these drops
prior to the OpenJDK build commencing.

The reason you hit a problem is because you're not building the
IcedTea forest.  You're (presumably) building the bsd-port forest and
it doesn't yet have:

http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/600bc3d048be
http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/26b97fd0e595

That should appear when bsd-port gets b77.  Prior to that, you could
just apply the changeset to the bsd-port tree locally.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[mvfranz]

Actually, I am not using the bsd port.  I just used the default configuration but enabled zero and shark.  I will look into the patches.

On Sat, Nov 7, 2009 at 8:06 PM, Andrew John Hughes <gnu_andrew@...> wrote:

2009/11/7 Michael Franz <mvfranz@...>:

> I have hit this bug.  Is there anyway to work around it during the build
> process?
>
> http://www.mail-archive.com/bug-classpath@.../msg06349.html
>
>

There already is a workaround.  If you check your build logs, you
should notice that the IcedTea build already downloads these drops
prior to the OpenJDK build commencing.

The reason you hit a problem is because you're not building the
IcedTea forest.  You're (presumably) building the bsd-port forest and
it doesn't yet have:

http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/600bc3d048be
http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/26b97fd0e595

That should appear when bsd-port gets b77.  Prior to that, you could
just apply the changeset to the bsd-port tree locally.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[gnu_andrew]

2009/11/8 Michael Franz <mvfranz@...>:

> Actually, I am not using the bsd port.  I just used the default
> configuration but enabled zero and shark.  I will look into the patches.
>
> On Sat, Nov 7, 2009 at 8:06 PM, Andrew John Hughes
> <gnu_andrew@...> wrote:
>>
>> 2009/11/7 Michael Franz <mvfranz@...>:
>> > I have hit this bug.  Is there anyway to work around it during the build
>> > process?
>> >
>> > http://www.mail-archive.com/bug-classpath@.../msg06349.html
>> >
>> >
>>
>> There already is a workaround.  If you check your build logs, you
>> should notice that the IcedTea build already downloads these drops
>> prior to the OpenJDK build commencing.
>>
>> The reason you hit a problem is because you're not building the
>> IcedTea forest.  You're (presumably) building the bsd-port forest and
>> it doesn't yet have:
>>
>> http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/600bc3d048be
>> http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/26b97fd0e595
>>
>> That should appear when bsd-port gets b77.  Prior to that, you could
>> just apply the changeset to the bsd-port tree locally.
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>
>

Then something is awry with your build.  If you can mail me config.log
and a full build.log I might have a better idea.  The IcedTea build
should download those files and put them in ${builddir}/drops.   Then
it sets ALT_DROPS_DIR=${builddir}/drops in the OpenJDK build and that
should be printed by ant prior to the bit you posted.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[mvfranz]

Andrew,

I sent you my logs directly, the message was too big for the list.  This is what I have tried (for the list).

I tried to build ppc with zero/shark - hit classpath bug
I tried to build ppc no zero/no shark and get the same results.
I tried the zero/shark configuration on intel and the build fails before it gets to the same location.
The default build on intel works fine.

Michael

[gnu_andrew]

2009/11/8 Michael Franz <mvfranz@...>:

> Andrew,
>
> I sent you my logs directly, the message was too big for the list.  This is
> what I have tried (for the list).
>
> I tried to build ppc with zero/shark - hit classpath bug
> I tried to build ppc no zero/no shark and get the same results.
> I tried the zero/shark configuration on intel and the build fails before it
> gets to the same location.
> The default build on intel works fine.
>
> Michael
>
>
>

You don't seem to be running the stamps/download-drops.stamp target at
all during the build.
Check that you have the latest tip:

$ hg tip
changeset:   2031:9eb43c172d5b
tag:         tip
user:        Andrew John Hughes <ahughes@...>
date:        Wed Nov 04 22:07:39 2009 +0000
summary:     Delete bootstrap/jdk1.7.0 on clean.

If you still have the build directory, try:

$ make download-drops
$ make

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[mvfranz]

On Sun, Nov 8, 2009 at 3:08 PM, Andrew John Hughes <gnu_andrew@...> wrote:

2009/11/8 Michael Franz <mvfranz@...>:

> Andrew,
>
> I sent you my logs directly, the message was too big for the list.  This is
> what I have tried (for the list).
>
> I tried to build ppc with zero/shark - hit classpath bug
> I tried to build ppc no zero/no shark and get the same results.
> I tried the zero/shark configuration on intel and the build fails before it
> gets to the same location.
> The default build on intel works fine.
>
> Michael
>
>
>

You don't seem to be running the stamps/download-drops.stamp target at
all during the build.
Check that you have the latest tip:

$ hg tip
changeset:   2031:9eb43c172d5b
tag:         tip
user:        Andrew John Hughes <ahughes@...>
date:        Wed Nov 04 22:07:39 2009 +0000
summary:     Delete bootstrap/jdk1.7.0 on clean.

If you still have the build directory, try:

$ make download-drops
$ make

This is what I have:
[mfranz@localhost icedtea]$ hg tip
changeset:   2031:9eb43c172d5b
tag:         tip
user:        Andrew John Hughes <ahughes@...>
date:        Wed Nov 04 22:07:39 2009 +0000
summary:     Delete bootstrap/jdk1.7.0 on clean.

[mfranz@localhost icedtea]$ make download-drops
make: Nothing to be done for `download-drops'.

I was using TIP before and noticed that it was always downloading the jar files after I did a clean.  It does not seem to be doing that now (I have pulled/updated since then).

I noticed that the stamps/download-drops.stamp is still there after a clean, but there is no drops directory.

So, I think the build process has changed while I was doing this.  The drops directory is no-longer deleted and the stamps are not removed.  However, I ended up with an empty drops directory but stamps indicating they were downloaded.

I removed the stamps directory and tried again.  The classpath error is no-longer an issue.

Michael

[gnu_andrew]

2009/11/8 Michael Franz <mvfranz@...>:

>
> On Sun, Nov 8, 2009 at 3:08 PM, Andrew John Hughes
> <gnu_andrew@...> wrote:
>>
>> 2009/11/8 Michael Franz <mvfranz@...>:
>> > Andrew,
>> >
>> > I sent you my logs directly, the message was too big for the list.  This
>> > is
>> > what I have tried (for the list).
>> >
>> > I tried to build ppc with zero/shark - hit classpath bug
>> > I tried to build ppc no zero/no shark and get the same results.
>> > I tried the zero/shark configuration on intel and the build fails before
>> > it
>> > gets to the same location.
>> > The default build on intel works fine.
>> >
>> > Michael
>> >
>> >
>> >
>>
>> You don't seem to be running the stamps/download-drops.stamp target at
>> all during the build.
>> Check that you have the latest tip:
>>
>> $ hg tip
>> changeset:   2031:9eb43c172d5b
>> tag:         tip
>> user:        Andrew John Hughes <ahughes@...>
>> date:        Wed Nov 04 22:07:39 2009 +0000
>> summary:     Delete bootstrap/jdk1.7.0 on clean.
>>
>> If you still have the build directory, try:
>>
>> $ make download-drops
>> $ make
>>
> This is what I have:
> [mfranz@localhost icedtea]$ hg tip
> changeset:   2031:9eb43c172d5b
> tag:         tip
> user:        Andrew John Hughes <ahughes@...>
> date:        Wed Nov 04 22:07:39 2009 +0000
> summary:     Delete bootstrap/jdk1.7.0 on clean.
>
> [mfranz@localhost icedtea]$ make download-drops
> make: Nothing to be done for `download-drops'.
>
> I was using TIP before and noticed that it was always downloading the jar
> files after I did a clean.  It does not seem to be doing that now (I have
> pulled/updated since then).
>

Yes, that's correct; I've made the tarballs only be deleted on a full
distclean (which gets rid of everything, including things like the
Makefile generated by configure).

> I noticed that the stamps/download-drops.stamp is still there after a clean,
> but there is no drops directory.
>
> So, I think the build process has changed while I was doing this.  The drops
> directory is no-longer deleted and the stamps are not removed.  However, I
> ended up with an empty drops directory but stamps indicating they were
> downloaded.
>
> I removed the stamps directory and tried again.  The classpath error is
> no-longer an issue.
>

So sounds like just a case of things changing in later revisions and
trying to use the same build directory.  This happens with tracking hg
and there's nothing we can really do to future-proof the build
directory against unknown future changes.  The easiest solution is to
do what I do and build in a separate directory which can then simply
be deleted when you start a fresh build.

> Michael
>



--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[tim.bell]

Andrew John Hughes wrote:
(snip...)

> So sounds like just a case of things changing in later revisions and
> trying to use the same build directory.  This happens with tracking hg
> and there's nothing we can really do to future-proof the build
> directory against unknown future changes.  The easiest solution is to
> do what I do and build in a separate directory which can then simply
> be deleted when you start a fresh build.

+1  --  When in doubt, rename or delete the previous build directory, then
start a new build from scratch...

Tim