5:58 a.m.
Hello,
I noticed that "BuildRequire: java-devel" is interpreted
differently on different architectures. Namely, it evaluates
java-1.5.0-gcj-devel on ppc{,64} and x86_64 but to
java-1.6.0-openjdk-devel on i586.
I observed this in rawhide koji.
This inconsistency brings various problems, like totally different
documentations builds between i586 and x86_64 (javadoc vs. sinjdoc)
or arch-dependent bugs, e.g., jni.h not found on i586 (#498964).
What's the intended default and who is the guilty one here?
Regards,
Stepan
9:51 a.m.
Stepan Kasal wrote:
I noticed that "BuildRequire: java-devel" is interpreted
differently on different architectures. Namely, it evaluates
java-1.5.0-gcj-devel on ppc{,64} and x86_64 but to
java-1.6.0-openjdk-devel on i586.
I observed this in rawhide koji.
This inconsistency brings various problems, like totally different
documentations builds between i586 and x86_64 (javadoc vs. sinjdoc)
or arch-dependent bugs, e.g., jni.h not found on i586 (#498964).
This isn't really a bug. If the package requires jni.h then it'll
be in /usr/lib/jvm/java/include, regardless of gcj or openjdk.
What's the intended default and who is the guilty one here?
Packages should generally be buildable on both. If they're not, they
can be marked, e.g. as dependent on openjdk.
The best defaults for koji are probably gcj on non-x86 machines and
openjdk on x86 machines. openjdk does work on PPC, but it is very slow
and will lead to much greater load on the PPC build boxes.
Andrew.
9:56 a.m.
On Tue, May 5, 2009 at 8:51 AM, Andrew Haley <aph(a)redhat.com> wrote:
Packages should generally be buildable on both. If they're not,
they
can be marked, e.g. as dependent on openjdk.
I've had to do this for a couple of my packages that build fine with
gcj, but whose documentation is not produced in an acceptable manner
by sinjdoc. It doesn't handle javadocs for annotation definitions,
for one thing.
--
Jerry James
http://www.jamezone.org/
9:58 a.m.
Jerry James wrote:
On Tue, May 5, 2009 at 8:51 AM, Andrew Haley <aph(a)redhat.com>
wrote:
> Packages should generally be buildable on both. If they're not, they
> can be marked, e.g. as dependent on openjdk.
I've had to do this for a couple of my packages that build fine with
gcj, but whose documentation is not produced in an acceptable manner
by sinjdoc. It doesn't handle javadocs for annotation definitions,
for one thing.
Yes, sinjdoc is rather old. If it doesn't do the job, then you'll have
to mark your package as dependent on openjdk.
Andrew.
10:27 a.m.
On 15:58 Tue 05 May , Andrew Haley wrote:
Jerry James wrote:
> On Tue, May 5, 2009 at 8:51 AM, Andrew Haley <aph(a)redhat.com> wrote:
>> Packages should generally be buildable on both. If they're not, they
>> can be marked, e.g. as dependent on openjdk.
>
> I've had to do this for a couple of my packages that build fine with
> gcj, but whose documentation is not produced in an acceptable manner
> by sinjdoc. It doesn't handle javadocs for annotation definitions,
> for one thing.
Yes, sinjdoc is rather old. If it doesn't do the job, then you'll have
to mark your package as dependent on openjdk.
Andrew.
--
fedora-devel-java-list mailing list
fedora-devel-java-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
Apologies for the off-topic question, but why is sinjdoc being used rather
than gjdoc? Neither are preferable over javadoc if available, but gjdoc
is at least known to be able to build the GNU Classpath documentation and
is maintained (now as part of gcj).
FWIW, in theory, there's actually no reason the langtools (tools.jar)
from OpenJDK couldn't be provided for archs using gcj. I've certainly
run the tools on Classpath VMs in the past.
--
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
10:31 a.m.
Andrew John Hughes wrote:
FWIW, in theory, there's actually no reason the langtools
(tools.jar)
from OpenJDK couldn't be provided for archs using gcj. I've certainly
run the tools on Classpath VMs in the past.
True, but it would be significant effort to create such a hybrid, and I don't
think that anyone will be madly keen to do the work.
Andrew.
12:43 p.m.
Andrew Overholt (overholt(a)redhat.com) said:
* Andrew Haley <aph(a)redhat.com> [2009-05-05 10:51]:
> The best defaults for koji are probably gcj on non-x86 machines and
> openjdk on x86 machines.
If I say "yum install java-devel" what gets installed? How is it
determined?
Via the comps file. The current java development group is attached. By
default, installing the group gets you the 'mandatory' and 'default'
packages.
The comps file does not have arch-specific bits, so doing gcj on
non-x86 and openjdk on x86 isn't really practical, without a lot
of metapackages.
Bill
5 a.m.
Hello,
On Tue, May 05, 2009 at 01:43:59PM -0400, Bill Nottingham wrote:
Andrew Overholt (overholt(a)redhat.com) said:
> * Andrew Haley <aph(a)redhat.com> [2009-05-05 10:51]:
> > The best defaults for koji are probably gcj on non-x86 machines and
> > openjdk on x86 machines.
>
> If I say "yum install java-devel" what gets installed? How is it
> determined?
Via the comps file. The current java development group is attached. By
default, installing the group gets you the 'mandatory' and 'default'
packages.
The comps file does not have arch-specific bits, so doing gcj on
non-x86 and openjdk on x86 isn't really practical, without a lot
of metapackages.
this explanation sort of confuses me. The current situation really
*is* what Andrew Haley proposed.
I guess that though the comps file does not have arch-specific bits,
the installation is determined by arch-specific dependencies in the
packages.
That was exactly what has brought my attention to this:
the differences between the two java's (e.g. that jni.h is installed
to the default include path by gcj but not by openjdk, different
javadocs) make the good old generic
BuildRequires: java-devel
very problematic, so I had to change it to
BuildRequires: java-1.5.0-gcj-devel
Well, my package builds fine with gcj and my conscience is clear as I
have reported this, so all is fine. :-)
Stepan
5:12 a.m.
Stepan Kasal wrote:
On Tue, May 05, 2009 at 01:43:59PM -0400, Bill Nottingham wrote:
> Andrew Overholt (overholt(a)redhat.com) said:
>> * Andrew Haley <aph(a)redhat.com> [2009-05-05 10:51]:
>>> The best defaults for koji are probably gcj on non-x86 machines and
>>> openjdk on x86 machines.
>> If I say "yum install java-devel" what gets installed? How is it
>> determined?
> Via the comps file. The current java development group is attached. By
> default, installing the group gets you the 'mandatory' and 'default'
> packages.
>
> The comps file does not have arch-specific bits, so doing gcj on
> non-x86 and openjdk on x86 isn't really practical, without a lot
> of metapackages.
this explanation sort of confuses me. The current situation really
*is* what Andrew Haley proposed.
I guess that though the comps file does not have arch-specific bits,
the installation is determined by arch-specific dependencies in the
packages.
That was exactly what has brought my attention to this:
the differences between the two java's (e.g. that jni.h is installed
to the default include path by gcj but not by openjdk, different
javadocs) make the good old generic
BuildRequires: java-devel
very problematic, so I had to change it to
BuildRequires: java-1.5.0-gcj-devel
Well, my package builds fine with gcj and my conscience is clear as I
have reported this, so all is fine. :-)
Sure, but it would make much more sense to look for jni.h in the right
place: then it would build with either. I would like to move jni.h out
of the compiler's default include path, but then God only knows what
else would break.
Andrew.
8:30 a.m.
Hallo,
On Wed, May 06, 2009 at 11:12:30AM +0100, Andrew Haley wrote:
Stepan Kasal wrote:
> the differences between the two java's (e.g. that jni.h is installed
> to the default include path by gcj but not by openjdk, different
> javadocs) make the good old generic
> BuildRequires: java-devel
> very problematic, so I had to change it to
> BuildRequires: java-1.5.0-gcj-devel
>
> Well, my package builds fine with gcj and my conscience is clear as I
> have reported this, so all is fine. :-)
Sure, but it would make much more sense to look for jni.h in the right
place: then it would build with either. I would like to move jni.h out
of the compiler's default include path, but then God only knows what
else would break.
well http://bugzilla.redhat.com/498964#c1 seems to recommend
for i in -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include{,/linux}; do
java_inc="$java_inc $i"
done
%configure CPPFLAGS="$java_inc"
But I'm afraid that this might not work with gcj or java-1.7.0-opejdk
(if it existed).
Ideally, I would have a solution general for all the javas, e.g.
BuildRequires: java-devel
%build
for i in -I/usr/include/java{,/linux}; do
java_inc="$java_inc $i"
done
%configure CPPFLAGS="$java_inc"
where /usr/include/java would be an alternatives-handled symlink.
Id that idea too wild? Is there anything a java-illiterate Fedora
packager can do to maka it happen?
Cheers,
Stepan
8:39 a.m.
Stepan Kasal wrote:
Hallo,
Hi.
On Wed, May 06, 2009 at 11:12:30AM +0100, Andrew Haley wrote:
> Stepan Kasal wrote:
>> the differences between the two java's (e.g. that jni.h is installed
>> to the default include path by gcj but not by openjdk, different
>> javadocs) make the good old generic
>> BuildRequires: java-devel
>> very problematic, so I had to change it to
>> BuildRequires: java-1.5.0-gcj-devel
>>
>> Well, my package builds fine with gcj and my conscience is clear as I
>> have reported this, so all is fine. :-)
> Sure, but it would make much more sense to look for jni.h in the right
> place: then it would build with either. I would like to move jni.h out
> of the compiler's default include path, but then God only knows what
> else would break.
well http://bugzilla.redhat.com/498964#c1 seems to recommend
for i in -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include{,/linux}; do
java_inc="$java_inc $i"
done
%configure CPPFLAGS="$java_inc"
But I'm afraid that this might not work with gcj or java-1.7.0-opejdk
(if it existed).
That's wrong. Use "-I/usr/lib/jvm/java/include/"
Symlinks work like this:
/usr/lib/jvm/java -->
/etc/alternatives/java_sdk -->
/usr/lib/jvm/java-1.6.0-openjdk.x86_64 -->
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64
or, if gcj is installed instead,
/usr/lib/jvm/java -->
/etc/alternatives/java_sdk -->
/usr/lib/jvm/java-1.5.0-gcj -->
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0
Andrew.
8:20 a.m.
Hello,
On Wed, May 06, 2009 at 02:39:01PM +0100, Andrew Haley wrote:
[...] Use "-I/usr/lib/jvm/java/include/"
Symlinks work like this:
/usr/lib/jvm/java -->
/etc/alternatives/java_sdk -->
/usr/lib/jvm/java-1.6.0-openjdk.x86_64 -->
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64
or, if gcj is installed instead,
/usr/lib/jvm/java -->
/etc/alternatives/java_sdk -->
/usr/lib/jvm/java-1.5.0-gcj -->
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0
indeed, this hint enabled me to make a spec file that builds both
with gcj and openjdk (see also http://bugzilla.redhat.com/498964#c2):
BuildRequires: java-devel
[...]
for i in -I/usr/lib/jvm/java/include{,/linux}; do
java_inc="$java_inc $i"
done
%configure CPPFLAGS="$java_inc"
Perhaps this could be part of Packaging:Java; I'm going to mail this
suggestion to fedora-packaging.
Stepan
8:39 a.m.
On Wed, 2009-05-06 at 15:30 +0200, Stepan Kasal wrote:
Id that idea too wild? Is there anything a java-illiterate Fedora
packager can do to maka it happen?
FWIW, the best I could think of for the OOo configure.in was
effectively...
class findhome {
public static void main(String args[]) {
System.out.println(System.getProperty("java.home"));
}
}
javac findhome.java
java findhome
e.g.
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
or
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre
and tack ../include onto that
C.
2:25 p.m.
* Bill Nottingham <notting(a)redhat.com> [2009-05-05 13:44]:
The comps file does not have arch-specific bits, so doing gcj on
non-x86 and openjdk on x86 isn't really practical, without a lot
of metapackages.
Any idea whey Stepan is seeing different "java-devel" packages being
picked on different arches in koji?
https://www.redhat.com/archives/fedora-devel-java-list/2009-May/msg00014....
Andrew
2:58 p.m.
Andrew Overholt (overholt(a)redhat.com) said:
* Bill Nottingham <notting(a)redhat.com> [2009-05-05 13:44]:
> The comps file does not have arch-specific bits, so doing gcj on
> non-x86 and openjdk on x86 isn't really practical, without a lot
> of metapackages.
Any idea whey Stepan is seeing different "java-devel" packages being
picked on different arches in koji?
https://www.redhat.com/archives/fedora-devel-java-list/2009-May/msg00014....
Oh, you meant litereally 'yum install java-devel', not 'yum groupinstall
java-development'. Sorry.
Given multiple providers of java-devel, this is determined by
compare_providers in yum (depsolve.py, if you want to read it). This
algorithm computes a score for the providers of java-devel, based
on the following:
1) whether one obsoletes the other
2) given the requesting package, whether the arch matches
3) given the requesting package, whether it comes from the same source RPM
4) given the requesting package, whether it shares a common name prefig
5) shorter name preferred
If you're just going from the command line, the first four won't show
a difference, so you're likely to get #5, shortest name.
Bill
3:01 p.m.
* Bill Nottingham <notting(a)redhat.com> [2009-05-08 15:58]:
5) shorter name preferred
$ rpm -q --whatprovides java-devel
java-1.5.0-gcj-devel-1.5.0.0-23.fc10.x86_64
java-1.6.0-openjdk-devel-1.6.0.0-15.b14.fc10.x86_64
According to Stepan, though, in koji he's getting the latter (OpenJDK)
for x86 and x86_64 and the former for non-x86*.
Andrew
3:11 p.m.
Andrew Overholt (overholt(a)redhat.com) said:
* Bill Nottingham <notting(a)redhat.com> [2009-05-08 15:58]:
> 5) shorter name preferred
$ rpm -q --whatprovides java-devel
java-1.5.0-gcj-devel-1.5.0.0-23.fc10.x86_64
java-1.6.0-openjdk-devel-1.6.0.0-15.b14.fc10.x86_64
According to Stepan, though, in koji he's getting the latter (OpenJDK)
for x86 and x86_64 and the former for non-x86*.
It may depend on what the requesting package is for his builds,
which could trigger the other rules mentioned.
Bill
4:13 a.m.
Hello,
On Fri, May 08, 2009 at 04:01:22PM -0400, Andrew Overholt wrote:
According to Stepan, though, in koji he's getting the latter
(OpenJDK)
for x86 and x86_64 and the former for non-x86*.
no, I'm getting openjdk for x86 and gcj for all other archs,
including x86_64.
The inconsistency on x86 multiarch is what first brought my attention
to this.
Actually, I think I know the answer now:`
On Fri, May 08, 2009 at 03:58:19PM -0400, Bill Nottingham wrote:
1) whether one obsoletes the other
2) given the requesting package, whether the arch matches
I believe this is the cause: gcj is still i386, and thus does not
match the requesting brltty.i586.
I can verify this by a rebuild of java-1.5.0-gcj, I'm going to try
this later today.
Have a nice day,
Stepan
11:19 a.m.
Hello again,
On Mon, May 11, 2009 at 11:13:24AM +0200, Stepan Kasal wrote:
On Fri, May 08, 2009 at 03:58:19PM -0400, Bill Nottingham wrote:
> 1) whether one obsoletes the other
> 2) given the requesting package, whether the arch matches
I believe this is the cause: gcj is still i386, and thus does not
match the requesting brltty.i586.
I can verify this by a rebuild of java-1.5.0-gcj, [...]
verified. The problem was that java-1.5.0-gcj escaped the F-11 Mass
Rebuild. I worked around the bug that prevented the rebuild, and now
gcj is preferred on all archs again, as you can check here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=1350608
https://koji.fedoraproject.org/koji/getfile?taskID=1350613&name=root.log
Stepan Kasal
12:39 p.m.
Stepan Kasal wrote:
Hello again,
On Mon, May 11, 2009 at 11:13:24AM +0200, Stepan Kasal wrote:
> On Fri, May 08, 2009 at 03:58:19PM -0400, Bill Nottingham wrote:
>> 1) whether one obsoletes the other
>> 2) given the requesting package, whether the arch matches
> I believe this is the cause: gcj is still i386, and thus does not
> match the requesting brltty.i586.
>
> I can verify this by a rebuild of java-1.5.0-gcj, [...]
verified. The problem was that java-1.5.0-gcj escaped the F-11 Mass
Rebuild. I worked around the bug that prevented the rebuild, and now
gcj is preferred on all archs again, as you can check here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=1350608
https://koji.fedoraproject.org/koji/getfile?taskID=1350613&name=root.log
OK, so we should be back to the status quo ante.
Thanks,
Andrew.
12:18 p.m.
Hi Stepan,
Stepan Kasal <skasal-H+wXaHxf7aLQT0dZR+AlfA(a)public.gmane.org> writes:
Hello,
I noticed that "BuildRequire: java-devel" is interpreted
differently on different architectures. Namely, it evaluates
java-1.5.0-gcj-devel on ppc{,64} and x86_64 but to
java-1.6.0-openjdk-devel on i586.
I observed this in rawhide koji.
This is not the behavior I would expect from koji. Since
java-1.6.0-openjdk-devel is available on ppc, ppc64 and x86_64, and
provides java-devel = 1:1.6.0, it should win against
java-1.5.0-gcj-devel which provides java-devel = 1.5.0.
I would ask the koji maintainers about this.
Tom
5456
days inactive
5463
days old
java-devel@lists.fedoraproject.org
22 comments
8 participants
participants (8)
-
Andrew Haley -
Andrew Hughes -
Andrew Overholt -
Bill Nottingham -
Caolán McNamara -
Jerry James -
Stepan Kasal -
Thomas Fitzsimmons