Hi,
On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my x86-64 system I get both the x86-64 and x86 packages. I suppose the x86 version is written last, because aot-compile-rpm's LIBDIR is set to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much breaks rpm building.
The fix is to make sure I just "yum install java-1.4.2-gcj-compat-devel.x86_64".
Is this expected behaviour? I don't remember this being a problem for my in the past.
Thanks,
AG
Anthony Green wrote:
On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my x86-64 system I get both the x86-64 and x86 packages. I suppose the x86 version is written last, because aot-compile-rpm's LIBDIR is set to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much breaks rpm building.
The fix is to make sure I just "yum install java-1.4.2-gcj-compat-devel.x86_64".
Is this expected behaviour? I don't remember this being a problem for my in the past.
Hmmm, a couple of months ago there was a big fuss about making sure multilib -devel packages could be installed simultaneously. I wonder if they changed yum to do something special with -devel packages. Do you have both i386 and x86_64 versions of java-1.4.2-gcj-compat installed? If so, maybe yum sees this and installs both -devel packages too?
Cheers, Gary
Anthony Green writes:
Hi,
On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my x86-64 system I get both the x86-64 and x86 packages. I suppose the x86 version is written last, because aot-compile-rpm's LIBDIR is set to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much breaks rpm building.
The fix is to make sure I just "yum install java-1.4.2-gcj-compat-devel.x86_64".
Is this expected behaviour? I don't remember this being a problem for my in the past.
AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is.
Andrew.
On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is.
Gary - do you think aot-compile-rpm could set LIBDIR based in part on the output of "gcj-dbtool -p" ? I think that would let us have identical scripts in both the 32- and 64-bit packages.
AG
Anthony Green wrote:
On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is.
Gary - do you think aot-compile-rpm could set LIBDIR based in part on the output of "gcj-dbtool -p" ? I think that would let us have identical scripts in both the 32- and 64-bit packages.
I don't see why not. Though I seem to recall we _used_ to set LIBDIR that way but changed to the present setup to solve a specific problem.
gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously? If so, and we do switch, which gcj-dbtool do you get?
Cheers, Gary
Gary Benson writes:
Anthony Green wrote:
On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is.
Gary - do you think aot-compile-rpm could set LIBDIR based in part on the output of "gcj-dbtool -p" ? I think that would let us have identical scripts in both the 32- and 64-bit packages.
I don't see why not. Though I seem to recall we _used_ to set LIBDIR that way but changed to the present setup to solve a specific problem.
gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously?
No. It's in /usr/bin.
Andrew.
Andrew Haley wrote:
Gary Benson writes:
Anthony Green wrote:
On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is.
Gary - do you think aot-compile-rpm could set LIBDIR based in part on the output of "gcj-dbtool -p" ? I think that would let us have identical scripts in both the 32- and 64-bit packages.
I don't see why not. Though I seem to recall we _used_ to set LIBDIR that way but changed to the present setup to solve a specific problem.
gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously?
No. It's in /usr/bin.
Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs?
Cheers, Gary
Gary Benson writes:
Andrew Haley wrote:
Gary Benson writes:
Anthony Green wrote:
On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is.
Gary - do you think aot-compile-rpm could set LIBDIR based in part on the output of "gcj-dbtool -p" ? I think that would let us have identical scripts in both the 32- and 64-bit packages.
I don't see why not. Though I seem to recall we _used_ to set LIBDIR that way but changed to the present setup to solve a specific problem.
gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously?
No. It's in /usr/bin.
Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs?
No, because libgcj.x86_64 contains both /usr/lib64/* and /usr/lib/*
Andrew.
On Mon, 2006-07-31 at 16:03 +0100, Gary Benson wrote:
gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously?
No. It's in /usr/bin.
Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs?
It looks like the jar files and man pages conflict so you can't install both at the same time (I tried to force it with "yum install libgcj.i386").
AG
On Mon, 2006-07-31 at 08:14 -0700, Anthony Green wrote:
On Mon, 2006-07-31 at 16:03 +0100, Gary Benson wrote:
gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously?
No. It's in /usr/bin.
Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs?
It looks like the jar files and man pages conflict so you can't install both at the same time (I tried to force it with "yum install libgcj.i386").
Interesting. I have a brp script that will be installed in the post install section of the rpm build to repack the jars with a consistent time stamp. This should correct the problem with the jar files.
The man page conflict is new to me - there's probably a time stamp or arch listing somewhere in them. A bug should be filed about this problem. Let me know if you would like me to file it.
Thanks, Ben
Ben Konrath wrote:
On Mon, 2006-07-31 at 08:14 -0700, Anthony Green wrote:
On Mon, 2006-07-31 at 16:03 +0100, Gary Benson wrote:
gcj-dbtool is in the libgcj rpm: can you have multiple copies of this installed simultaneously?
No. It's in /usr/bin.
Really? So no simultaneous libgcj.i386 and libgcj.x86_64 installs?
It looks like the jar files and man pages conflict so you can't install both at the same time (I tried to force it with "yum install libgcj.i386").
Interesting. I have a brp script that will be installed in the post install section of the rpm build to repack the jars with a consistent time stamp. This should correct the problem with the jar files.
The man page conflict is new to me - there's probably a time stamp or arch listing somewhere in them. A bug should be filed about this problem. Let me know if you would like me to file it.
There's still all the stuff in /usr/bin anyway. That's going to be different no matter what you do to it.
Cheers, Gary
Anthony Green wrote:
On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
AFAIK it's the default yum behaviour: multilibbed libraries install all arches. That seems a litttle weird, but there it is.
Gary - do you think aot-compile-rpm could set LIBDIR based in part on the output of "gcj-dbtool -p" ? I think that would let us have identical scripts in both the 32- and 64-bit packages.
Ok, ftp://sources.redhat.com/pub/rhug/java-gcj-compat-1.0.62.tar.gz does this. Sorry for the wait...
Cheers, Gary
java-devel@lists.fedoraproject.org
-
Andrew Haley -
Anthony Green -
Benjamin Konrath -
Gary Benson