On Sunday 08 February 2004 15:13, Gene C. wrote:
I am not sure if this belongs on the fedora-devel or the fedora-test
but since most of the discussion on FC1 x86_64 test1 has been here, this is
the list I am using.
The version of gcc packaged with test1 (3.3.2-5) has a bug which causes the
compiler to loop. This was fixed in 3.3.2-6 and works fine. When I was
asked about this in the bugzilla report I had submitted, I noticed that
development now had 3.3.2-8 rather than 3.3.2-6 and I decided to rebuild
again (not as bad as rebuilding XFree86 but take a long time anyway).
I looked a bit closer at the build printed output this time and noticed
that a number of files (libraries) where "Installed (but unpackaged)".
Looking closer at the list of these files I realized that the 32 bit
libraries had been generated as well as the 64 bit versions ... reasonable
since gcc on the x86_64 is capable of generating both 32 bit and 64 bit
But not all 32 bit libraries were listed. Checking some of the packages
such as libobjc showed the reason why ... it had both the 32 bit and 64 bit
Now my question concerning consistency -- how should gcc (and by
implication glibc) be packaged for the x86_64? As I see it, there are two
1. Only the 64 bit versions should be packaged as x86_64 rpms but do this
for all packages and require that the ix86 packages be installed if 32 bit
support is needed.
2. Build and distribute both the 32 bit and 64 bit libraries as x86_64
rpms. If this is done for gcc, then it should also be done for glibc.
I can see arguments either way.
Any comments? Should I file a bugzilla report on this?
OK, I am answering my own question ...
There is no packaging consistency problem. I need to learn to use "rpm -qil"
rather than "rpm -ql" on the x86_64 so that I get the files listed with their
package and not all together so that it gives the wrong impression.
There is still a problem with test1 in that the 32 versions of libgnat and
libf2c are missing. This will be bugzilla'ed.