But gcc, when built from FSF gcc sources, does that correctly. The
Fedora RPM, when built using rpmbuild, works correctly. We know that,
because we build it all the time, and we build Fedora with it.
No, it does not! Look at my previous posts. When I finish building gcc
using gcc.spec I end up with about 10 rpms none of which is for the
.i686 architecture (libgcc.i686 isn't there either) - the precise point
I have made all along. Read my previous posts before writing something
like the above.
We also know that there's no need to change the specfile to get the RPMs.
If I do not change the spec file I will have ada, gcc-java (with a build
error - again, see my previous posts as I am not going to post that
again) and having spend/wasted 2 hours (out of the 3 needed for
compiling GCC) running tests which I did not want. There is absolutely
no way I can disable these unless I edit gcc.spec, which is, at best a
very poor design practice (look for the spec file for the kernel if you
want to see how to design a good spec file with different elements
enabled/disabled by using the --with/--without command line options when
running rpmbuild).
At the end of the build process I will have NO i686 packages in my RPMS
directory - just those for the host architecture. When I install them
all, I end up without what I have wanted/requested originally -
cross-compiling (try -m32 and see if it works - my guess is that it
won't!).
I also have a bunch of dead links which prevent GCC to function properly
and I have to additionally download and install the corresponding i686
GCC packages (which should have been compiled/built as part of the main
built!) to make the whole thing work. This has already been mentioned in
my previous posts so it is the last time I am repeating it here - just
for your own benefit.
I don't know what you did.
Please refer to my posts on this very thread.
It seems as though you expect the RPM
build of gcc to build you a cross compiler and all the i686 target
libraries. But that's not what it's supposed to do. The 32-bit
libraries are built as part of the 32-bit distro.
When I request GCC to be built as a cross compiler I expect at the end
of this process to have (at least) all packages - x86_64 and i686 alike
- which are part of GCC to be built so that GCC can function as a...
erm... cross compiler! I do not expect to end up with some half-ars*d
job where I only have packages for my host architecture which does NOT
allow GCC to function as a cross compiler (something I have requested in
a first place).
When you compile/build a kernel you expect to end up with the kernel and
the associated firmwares and debug-packages built at the end of it - you
do not go around searching for these because that is part of the build
up process and they are already build for you. The same is not true for
GCC - the point I am trying to make all along.
There is clearly some mismatch of expectations, or some mistake in procedure.
There is no mismatch - just common sense. The same common sense which
tells me that whoever created gcc.spec need to have a good hard look at
themselves as the amount of flexibility which it gives to developers
like myself is grand total of zero, let alone that it does NOT do the
job it is designed to do - build GCC.
If you spend 5 minutes to look through my posts on this thread you will
see what I have in mind. Failing that, take a closer look at the spec
file for the kernel if you want to see a good example of how a spec file
should be designed.
