Ditto. --32 is not a valid GCC option.
AFAIK, it is - "gcc --help" tells me otherwise!
You shouldn't get any errors. Are you sure all the dependencies are
installed?
sudo yum-builddep gcc
I had to *manually* install glibc.i686 and glibc-devel.i686 - these packages should have been picked up as a dependencies automatically by Fedora - they were NOT!
Talk to Fedora about that, this list is for gcc help.
Apologies for this - as I pointed out in my initial post when starting
this thread, I couldn't find a Fedora-specific GCC mailing list to
initiate this thread as my issue is not really with GCC, but more to do
with Fedora's distribution package and the way it is built using their
gcc.spec file.
None of the rpm or manual built of GCC picked the dependency on libgcc.i686 either (executing yum-builddep gcc-4.4.5-2.fc13.src.rpm lists all the dependencies EXCEPT for libgcc.i686).
Again, talk to Fedora.
If I know how/where I will...The only way I can think of is to submit a
bug via Bugzilla.
There is another problem though -
[root@test1 ~]# ls -las /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/
total 3464
4 drwxr-xr-x. 2 root root 4096 Nov 26 23:40 .
4 drwxr-xr-x. 4 root root 4096 Nov 26 23:40 ..
4 -rw-r--r--. 1 root root 1740 Nov 26 20:46 crtbegin.o
4 -rw-r--r--. 1 root root 2164 Nov 26 20:46 crtbeginS.o
4 -rw-r--r--. 1 root root 2048 Nov 26 20:46 crtbeginT.o
4 -rw-r--r--. 1 root root 1312 Nov 26 20:46 crtend.o
4 -rw-r--r--. 1 root root 1568 Nov 26 20:46 crtendS.o
4 -rw-r--r--. 1 root root 4088 Nov 26 20:46 crtfastmath.o
4 -rw-r--r--. 1 root root 2100 Nov 26 20:46 crtprec32.o
4 -rw-r--r--. 1 root root 2108 Nov 26 20:46 crtprec64.o
4 -rw-r--r--. 1 root root 2100 Nov 26 20:46 crtprec80.o
3236 -rw-r--r--. 1 root root 3311740 Nov 26 20:46 libgcc.a
48 -rw-r--r--. 1 root root 45148 Nov 26 20:46 libgcc_eh.a
0 lrwxrwxrwx. 1 root root 18 Nov 26 23:40 libgcc_s.so -> /lib/libgcc_s.so.1
36 -rw-r--r--. 1 root root 33982 Nov 26 20:46 libgcov.a
92 -rw-r--r--. 1 root root 92262 Nov 26 20:46 libgomp.a
-->-----
0 lrwxrwxrwx. 1 root root 28 Nov 26 23:40 libgomp.so -> ../../../../libgomp.so.1.0.0
0 lrwxrwxrwx. 1 root root 45 Nov 26 23:40 libmudflap.a -> ../../../i686-redhat-linux/4.4.5/libmudflap.a
---<-----
4 -rw-r--r--. 1 root root 39 Nov 26 20:46 libmudflap.so
-->-----
0 lrwxrwxrwx. 1 root root 47 Nov 26 23:40 libmudflapth.a -> ../../../i686-redhat-linux/4.4.5/libmudflapth.a
---<-----
4 -rw-r--r--. 1 root root 41 Nov 26 20:46 libmudflapth.so
-->-----
0 lrwxrwxrwx. 1 root root 44 Nov 26 23:40 libstdc++.a -> ../../../i686-redhat-linux/4.4.5/libstdc++.a
0 lrwxrwxrwx. 1 root root 31 Nov 26 23:40 libstdc++.so -> ../../../../libstdc++.so.6.0.13
0 lrwxrwxrwx. 1 root root 44 Nov 26 23:40 libsupc++.a -> ../../../i686-redhat-linux/4.4.5/libsupc++.a
---<-----
The symlinks above (with the exception of libgcc_s.so.1 which is OK once I MANUALLY install libgcc.i686) are all DEAD - none of these files are installed by gcc or any other package, nor are they picked up as a required dependency. I do not think that's right.
Those files come from glibc, specifically the glibc-devel.i686 package.
No, they are not! The last 3 DEAD symlinks come from libstdc++.i686,
which is (or should be as its x86_64 counterpart is compiled in) part of
the GCC packages (at least that is the case with Fedora). Again, that is
not compiled in when I build GCC, only libstdc++.x86_64 rpm is built at
the end of it, libstdc++.i686 is NOT. libmudflap* is also built as part
of the GCC package on Fedora, but again, the i686 counterpart is NOT
built nor is it provided. Same goes for the libgomp.i686 package -
x86_64 is built, libgomp.i686 is not built, nor provided. Madness -
multilib my ar**!
Oh, and don't start me on the gcc.spec file itself - I haven't seen so badly organised spec file for quite a while (and I am in IT for more than 17 years): whoever was involved in creating this file should stop sniffing glue!
This has nothing to do with GCC, the spec file for the gcc package in
Fedora is written by Fedora people.
I agree and, again, I can only apologise - as I already pointed out this
is indeed a Fedora-specific problem for GCC...
For starters who's bright spark's idea was it that I would definitely NEED ada or GCC-Java installed/built by default, occupying/wasting an additional couple of megabytes (not to mention the compile time needed to build these - GCC-Java in particular)? Unless I manually edit and disable the ada and gcc-java stuff there is no way this is not getting compiled.
That was someone at Fedora's idea. When they use the spec file they
want it to build those components so they can ship the relevant
packages. If you don't want all of them, edit the spec file.
This is Micro$oft Windoze mentality! I should at least be able to
specify (via the appropriate --with/--without command line options) what
I need/don't need compiled in without the need to edit the file - this
is exactly how it is done with the kernel and countless other rpm
packages - it is a good design practice, but what we have with gcc.spec
is nothing short of shambolic!
Not to mention the fact that 2/3 of the time needed to build the GCC package is wasted on running the tests (that is 2 hours WASTED on my x86_64 machine!) - again, without an easy option to disable these (the only way I can do that is to find and comment the lines in the gcc.spec file where these tests get executed - absolute madness!).
Talk to Fedora about that too.
The $60m question is - where to find those responsible for this? I would
have, if I knew (and would not have initiated this thread in here in the
first place).
Now, for the reason why the compilation failed (and why I created this thread) - as I was using one shell instance and have experimented quite a bit before deciding to manually try and build GCC I have wrongly inserted ARCH=i386 environment variable (and forgot about it) so I presume that is why everything was falling apart.
Don't do that then ;-)
IIRC the Fedora spec file is quite specific to the use-case of
building all GCC packages, for the Fedora distro. It possibly assumes
that to build the i686 packages you will build on i686, which might be
why the 32bit glibc packages aren't listed as build dependencies.
Which is completely wrong assumption simply because if I select a
multilib option I expect ALL packages to be built, which is not the case
here at all.
