building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

> 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.