>Maybe the libgcc-4.4.5-2.fc13.i686 package isn't installed.
>
> sudo yum install libgcc.i686
This seems to have (partially) worked.
[zeek@test1 t]$ gcc -o hello -m32 hello.c
[zeek@test1 t]$ file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
That's OK, though when I execute this:
1.
[zeek@test1 t]$ gcc -o hello -march=i686 hello.c
hello.c:1: error: CPU you selected does not support x86-64 instruction set
2.
[zeek@test1 t]$ gcc -o hello -march=pentium2 hello.c
hello.c:1: error: CPU you selected does not support x86-64 instruction set
hello.c:1: error: CPU you selected does not support x86-64 instruction set
3.
[zeek@test1 t]$ gcc -o hello -march=pentium2 --32 hello.c
cc1: error: unrecognized command line option "-f32"
hello.c:1: error: CPU you selected does not support x86-64 instruction set
hello.c:1: error: CPU you selected does not support x86-64 instruction set
4.
[zeek@test1 t]$ gcc -o hello -march=pentium4 -m32 hello.c
[zeek@test1 t]$ file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
For the last statement I was expecting the CPU to be Pentium 4 (i686)
and not "Intel 80386".
>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! When I successfully compiled the whole GCC
package (see below) the above 2 packages were not compiled/built either!
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).
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.
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!
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.
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!).
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.
When I rebooted the machine everything was OK - that, after I, again,
manually edited/sanitised gcc.spec to remove the building of ada and
GCC-Java - the latter could not pass as I was getting the following error:
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
*******************************************************************************
*
* WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild'
* to fail. To ignore these errors, you can set the '$QA_RPATHS'
* environment variable which is a bitmask allowing the values
* below. The current value of QA_RPATHS is 0x0000.
*
* 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
* issue but are introducing redundant searchpaths without
* providing a benefit. They can also cause errors in multilib
* environments.
* 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
* nor relative filenames and can therefore be a SECURITY risk
* 0x0004 ... insecure RPATHs; these are relative RPATHs which are a
* SECURITY risk
* 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
* RPATHs; this is just a minor issue but usually unwanted
* 0x0010 ... the RPATH is empty; there is no reason for such RPATHs
* and they cause unneeded work while loading libraries
* 0x0020 ... an RPATH references '..' of an absolute path; this will
break
* the functionality when the path before '..' is a symlink
*
*
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
* $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute
check-rpaths like
* $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
*
*******************************************************************************
ERROR 0020: file '/usr/lib64/gcj-4.4.4/libjawt.so' contains an rpath
referencing '..' of an absolute path [/usr/lib/../lib64/gcj-4.4.5]
error: Bad exit status from /var/tmp/rpm-tmp.QfHEw0 (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.QfHEw0 (%install)
