Re: building gcc 4.4.5 from source on Fedora 13

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

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

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

> You now know the packages you needed to install, if you don't like the Fedora spec file report it as a Fedora bug.
>   
I would, don't you worry about that!

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 1 December 2010 13:52, Mr Dash Four wrote:
>
> This is not the case - as it turns out the GCC package offered by Fedora is
> NOT a cross-compiler, but it is sixty-four-bit-only version of the GCC and
> if one wants a truly cross-compiling GCC it has to spend a week or so on
> this mailing list to find out what is required.

Stop being such a drama queen. This mailing list was never the right
place to ask anyway.  You now know the packages you needed to install,
if you don't like the Fedora spec file report it as a Fedora bug.

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

> Why don't you just install the necessary (x86_64 and i686) packages on
> those other machines?
>   
If I am building from source (SRPMs) I expect everything to be built and 
not scramble around looking for additional RPMs which are part of the 
same package I am supposedly building 'from source'.

> Yep, but didn't we already establish you don't need to anyway, you're
> just ranting about a spec file which does what it's designed to do,
> but not what you want?
>   
Aye, if by above you mean that gcc.spec is designed to compile 
sixty-four-bit-only GCC, including support for such commonly-used 
programming languages like ada, GCC-Java (no Fedora distribution should 
be without it!), giving the grant total of zero flexibility to configure 
any part of the GCC built, than gcc.spec does an absolutely marvellous 
job - no question!

Oh, of course, I nearly forgot the tests - watching that mighty, 
freshly-compiled sixty-four-bit-only GCC perform number-crunching for 
two whole hours as part of that built and seeing those numbers roll on 
my screen is just a jot to watch - absolutely magnificent!

If, on the other hand, one wants to build GCC which truly 
cross-compiles, has the ability to exclude languages which are not 
needed during that built (and save some built time in the process), has 
the ability to exclude the tests (which take 2/3 of the build up, no 
less) and expect at the end of that built to have all the necessary GCC 
packages which enable it to function properly - as a cross-compiler, 
then the current version of gcc.spec does NOT do that and is unsuitable 
for that purpose.

> Just install the necessary packages using yum.
>   
As I already pointed out I, as a user, do not expect to play the role of 
RPM and chase dependencies all day long - I expect when I select GCC to 
be installed (whether via yum, yumdownloader or the rpm itself) and, as 
it has already been established GCC is, supposedly, pre-built by Fedora 
to be a 'cross-compiler', then I expect all the necessary dependencies 
(x86_64 and i686 alike) to be satisfied when that package is installed.

This is not the case - as it turns out the GCC package offered by Fedora 
is NOT a cross-compiler, but it is sixty-four-bit-only version of the 
GCC and if one wants a truly cross-compiling GCC it has to spend a week 
or so on this mailing list to find out what is required.

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 30 November 2010 19:27, Mr Dash Four wrote:
>
>>> Functioning GCC - yes. GCC functioning as a cross-compiler - NO!
>>>
>>
>> *sigh* If you build from SRPM, no.
>>  [...]
>>
>> You're talking about building RPMs from SRPMs using rpmbuild and a spec
>> file.
>>
>> I'm not.
>>
>> [...]
>> For the last time, I'm not talking about building with a spec file.
>>
>
> Fair enough - I was assuming that you were. I cannot comment on building GCC
> from source (other than using SRPMs) as I do not wish to build GCC without
> creating the necessary RPMs for the simple reason that I won't be able to
> install it on other machines, so I need GCC (cross-compiling), neatly
> packaged, so that it be can easily installed on other machines.

Why don't you just install the necessary (x86_64 and i686) packages on
those other machines?

>>> Right from the start Andrew have said that GCC, by default, when
>>> installed,
>>> is cross-compiling. That, clearly, is not the case as I already pointed
>>> out
>>> on numerous occasions. If you think that it is, then keep dreaming and
>>> best
>>> of luck!
>>>
>>
>> I do it several times a week.
>>
>
> What? Dreaming?!

Build a multilib gcc, from source.

>> The way it works now means they can have it their way and you can have
>> it your way, if you install some additional packages.
>>
>
> But I still can't build it from source (SRPM!) and end up with everything
> which needs to be installed in order for GCC to function as a
> cross-compiler. In other words at the end of the process I do not end up
> with the necessary mixture of x86_64 and i686 packages, but only the x86_64
> (or whatever the host architecture is) group of packages are created.

Yep, but didn't we already establish you don't need to anyway, you're
just ranting about a spec file which does what it's designed to do,
but not what you want?

Just install the necessary packages using yum.

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

>> Functioning GCC - yes. GCC functioning as a cross-compiler - NO!
>>     
>
> *sigh* If you build from SRPM, no.
>   
> [...]
>
> You're talking about building RPMs from SRPMs using rpmbuild and a spec file.
>
> I'm not.
>
> [...]
> For the last time, I'm not talking about building with a spec file.
>   
Fair enough - I was assuming that you were. I cannot comment on building 
GCC from source (other than using SRPMs) as I do not wish to build GCC 
without creating the necessary RPMs for the simple reason that I won't 
be able to install it on other machines, so I need GCC 
(cross-compiling), neatly packaged, so that it be can easily installed 
on other machines.

>> Right from the start Andrew have said that GCC, by default, when installed,
>> is cross-compiling. That, clearly, is not the case as I already pointed out
>> on numerous occasions. If you think that it is, then keep dreaming and best
>> of luck!
>>     
>
> I do it several times a week.
>   
What? Dreaming?!

> The way it works now means they can have it their way and you can have
> it your way, if you install some additional packages.
>   
But I still can't build it from source (SRPM!) and end up with 
everything which needs to be installed in order for GCC to function as a 
cross-compiler. In other words at the end of the process I do not end up 
with the necessary mixture of x86_64 and i686 packages, but only the 
x86_64 (or whatever the host architecture is) group of packages are created.

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 30 November 2010 19:04, Mr Dash Four wrote:
>
>>> Yes, it is true that I originally wanted to use GCC as a cross compiler
>>> and
>>> because it did not work I set myself to build it from source to correct
>>> that
>>> mistake. Later on it was established that GCC, supposedly, should already
>>> function as a cross compiler which later on transpired NOT to be the case
>>> as
>>>
>>
>> It patently *is* the case that GCC can function in that way, and it's
>> the default if you build from source.
>>
>
> Functioning GCC - yes. GCC functioning as a cross-compiler - NO!

*sigh* If you build from SRPM, no.

But if you build from source (not from an SRPM) following the
instructions at http://gcc.gnu.org/install/ then it works fine. I do
it several times a week. On Fedora.  Again, not from an SRPM using a
spec file.

Of course, to actually compile 32-bit software I need glibc-devel.i686
installed too.
But the GCC I build, FROM SOURCE, is a multilib compiler with 64-bit
and 32-bit libstdc++ installed.

> Not, unless one spends a few days writing in this mailing list until it
> becomes clear that a couple of additional *GCC* packages need to be
> installed for GCC to function as 'advertised', i.e. with the
> cross-compilation working.

You're talking about building RPMs from SRPMs using rpmbuild and a spec file.

I'm not.

>>> when I was installing the *Fedora-distributed* GCC RPM all the i686
>>> dependencies which enable GCC to function as a cross compiler were not
>>> picked up and subsequently not installed. If they were I won't be
>>> starting
>>> this thread in this mailing list.
>>>
>>
>> And Andrew and I have both said why the 32-bit "dependencies" are not
>> hard dependencies: because that way it's not possible to get a
>> 64-bit-only compiler.
>
> Right from the start Andrew have said that GCC, by default, when installed,
> is cross-compiling. That, clearly, is not the case as I already pointed out
> on numerous occasions. If you think that it is, then keep dreaming and best
> of luck!

I do it several times a week.

> Besides, I am not at all interested in getting '64-bit-only' compiler - that
> is not the purpose I started this thread. I am interested in getting a
> cross-compiler. To me the term 'cross-compiling' means to be able to compile
> binaries for more than one architecture (i686 and x86_64 in my case).

Right, but *other people* are interested in that.

The way it works now means they can have it their way and you can have
it your way, if you install some additional packages.

> They way things are at present, GCC, as installed by Fedora, does NOT
> cross-compile, despite what you, Andrew, John Doe or whoever else may claim.
> It may be a '64-bit-only' compiler, yes, but certainly isn't a
> cross-compiler.

Yes, because you need to install some i686 packages.

> Secondly, if I want to build GCC purely from source as a cross-compiler
> (yes, from source - without using additional binaries from the same package)
> using the gcc.spec file I can't - not without extensive editing and messing
> about with the said file and even then I would still need to install
> additional GCC binaries (binaries from the same group of packages I am
> trying to build, no less!) in order to make the whole thing work!
>
> If you, Andrew or anyone else think that's OK - well, keep deluding
> yourselves.

For the last time, I'm not talking about building with a spec file.

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

>> Yes, it is true that I originally wanted to use GCC as a cross compiler and
>> because it did not work I set myself to build it from source to correct that
>> mistake. Later on it was established that GCC, supposedly, should already
>> function as a cross compiler which later on transpired NOT to be the case as
>>     
>
> It patently *is* the case that GCC can function in that way, and it's
> the default if you build from source.
>   
Functioning GCC - yes. GCC functioning as a cross-compiler - NO!

Not, unless one spends a few days writing in this mailing list until it 
becomes clear that a couple of additional *GCC* packages need to be 
installed for GCC to function as 'advertised', i.e. with the 
cross-compilation working.

>> when I was installing the *Fedora-distributed* GCC RPM all the i686
>> dependencies which enable GCC to function as a cross compiler were not
>> picked up and subsequently not installed. If they were I won't be starting
>> this thread in this mailing list.
>>     
>
> And Andrew and I have both said why the 32-bit "dependencies" are not
> hard dependencies: because that way it's not possible to get a
> 64-bit-only compiler.
Right from the start Andrew have said that GCC, by default, when 
installed, is cross-compiling. That, clearly, is not the case as I 
already pointed out on numerous occasions. If you think that it is, then 
keep dreaming and best of luck!

Besides, I am not at all interested in getting '64-bit-only' compiler - 
that is not the purpose I started this thread. I am interested in 
getting a cross-compiler. To me the term 'cross-compiling' means to be 
able to compile binaries for more than one architecture (i686 and x86_64 
in my case).

They way things are at present, GCC, as installed by Fedora, does NOT 
cross-compile, despite what you, Andrew, John Doe or whoever else may 
claim. It may be a '64-bit-only' compiler, yes, but certainly isn't a 
cross-compiler.

Secondly, if I want to build GCC purely from source as a cross-compiler 
(yes, from source - without using additional binaries from the same 
package) using the gcc.spec file I can't - not without extensive editing 
and messing about with the said file and even then I would still need to 
install additional GCC binaries (binaries from the same group of 
packages I am trying to build, no less!) in order to make the whole 
thing work!

If you, Andrew or anyone else think that's OK - well, keep deluding 
yourselves.

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 30 November 2010 14:45, Mr Dash Four wrote:
>
>>> 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.
>>>
>>
>> The job it's designed to do is build GCC RPMs *for Fedora* in order to
>> distribute RPMs for Fedora. It's not necessarily meant for end users
>> to rebuild packages that they can just install from a repo (because
>> we've already established you didn't really need to build from source
>> anyway, you just needed to install some additional packages - and in
>> fact building from source *still* doesn't do what you want - even more
>> reason to just install those additional packages and be done with it.)
>>
>
> Yes, it is true that I originally wanted to use GCC as a cross compiler and
> because it did not work I set myself to build it from source to correct that
> mistake. Later on it was established that GCC, supposedly, should already
> function as a cross compiler which later on transpired NOT to be the case as

It patently *is* the case that GCC can function in that way, and it's
the default if you build from source.

> when I was installing the *Fedora-distributed* GCC RPM all the i686
> dependencies which enable GCC to function as a cross compiler were not
> picked up and subsequently not installed. If they were I won't be starting
> this thread in this mailing list.

And Andrew and I have both said why the 32-bit "dependencies" are not
hard dependencies: because that way it's not possible to get a
64-bit-only compiler.  If those "dependencies" are optional extras
then you can choose whether or not to install them.  In your case, you
want them, so install them.  So they weren't installed automatically
and you needed to be told which additional packages to install, get
over it, or at the very least take it up with Fedora not here.

>> Andrew said "But that's not what it's supposed to do.  The 32-bit
>> libraries are built as part of the 32-bit distro."
>> IIUC to get the i686 packages you need to build on i686. Rightly or
>> wrongly, building on x86_64 gets you the 64bit packages, and the 32bit
>> ones come from a separate repo that was built for i686, on i686.  (I
>> think the glibc rpm spec file might behave the same way.)
>>
>
> My point all along is that if I want to get GCC to function as a cross
> compiler (its 'default' behaviour, as I've been told!) then I should be able
> to run the spec file and end up with all the necessary GCC packages allowing
> GCC to function as such. That is not the case!

If you build GCC from source, you get a multilib compiler.  That's the
default behaviour when building from source.  Building from Fedora's
spec file is a different use case, with different behaviour.

Your rant is now turning into "it's possible to build GCC in a certain
way, the spec file is broken if it doesn't do it that way!"

Whereas in fact the spec file is designed for a different situation,
for good reasons.

>> You want the spec file to be useful for a different use case, which
>> while reasonable, may not be the use case the spec file was actually
>> written for.  That doesn't mean the spec file is broken, it just means
>> your expectations don't match what the spec file was written to do.
>>
>
> The spec file IS broken as it does not build the necessary GCC packages
> allowing GCC to function as a cross compiler - simple as that really.

It does what it's designed to do, which is not the same as the the GCC
build system.

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

>> 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.
>>     
>
> The job it's designed to do is build GCC RPMs *for Fedora* in order to
> distribute RPMs for Fedora. It's not necessarily meant for end users
> to rebuild packages that they can just install from a repo (because
> we've already established you didn't really need to build from source
> anyway, you just needed to install some additional packages - and in
> fact building from source *still* doesn't do what you want - even more
> reason to just install those additional packages and be done with it.)
>   
Yes, it is true that I originally wanted to use GCC as a cross compiler 
and because it did not work I set myself to build it from source to 
correct that mistake. Later on it was established that GCC, supposedly, 
should already function as a cross compiler which later on transpired 
NOT to be the case as when I was installing the *Fedora-distributed* GCC 
RPM all the i686 dependencies which enable GCC to function as a cross 
compiler were not picked up and subsequently not installed. If they were 
I won't be starting this thread in this mailing list.


> Andrew said "But that's not what it's supposed to do.  The 32-bit
> libraries are built as part of the 32-bit distro."
> IIUC to get the i686 packages you need to build on i686. Rightly or
> wrongly, building on x86_64 gets you the 64bit packages, and the 32bit
> ones come from a separate repo that was built for i686, on i686.  (I
> think the glibc rpm spec file might behave the same way.)
>   
My point all along is that if I want to get GCC to function as a cross 
compiler (its 'default' behaviour, as I've been told!) then I should be 
able to run the spec file and end up with all the necessary GCC packages 
allowing GCC to function as such. That is not the case!

> You want the spec file to be useful for a different use case, which
> while reasonable, may not be the use case the spec file was actually
> written for.  That doesn't mean the spec file is broken, it just means
> your expectations don't match what the spec file was written to do.
>   
The spec file IS broken as it does not build the necessary GCC packages 
allowing GCC to function as a cross compiler - simple as that really.

Re: building gcc 4.4.5 from source on Fedora 13

[Andrew Haley]

On 11/30/2010 02:33 PM, Jonathan Wakely wrote:
> This is still off-topic for this list...
> 
> On 30 November 2010 14:19, Mr Dash Four wrote:
>>
>> 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.
> 
> The job it's designed to do is build GCC RPMs *for Fedora* in order to
> distribute RPMs for Fedora. It's not necessarily meant for end users
> to rebuild packages that they can just install from a repo (because
> we've already established you didn't really need to build from source
> anyway, you just needed to install some additional packages - and in
> fact building from source *still* doesn't do what you want - even more
> reason to just install those additional packages and be done with it.)
> 
> Andrew said "But that's not what it's supposed to do.  The 32-bit
> libraries are built as part of the 32-bit distro."
> IIUC to get the i686 packages you need to build on i686. Rightly or
> wrongly, building on x86_64 gets you the 64bit packages, and the 32bit
> ones come from a separate repo that was built for i686, on i686.

That's right, and we do it that way to make sure we have only one set of
32-bit libraries.

Andrew.

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 30 November 2010 14:33, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> This is still off-topic for this list...
>
> On 30 November 2010 14:19, Mr Dash Four wrote:
>>
>> 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.
>
> The job it's designed to do is build GCC RPMs *for Fedora* in order to
> distribute RPMs for Fedora. It's not necessarily meant for end users
> to rebuild packages that they can just install from a repo (because
> we've already established you didn't really need to build from source
> anyway, you just needed to install some additional packages - and in
> fact building from source *still* doesn't do what you want - even more
> reason to just install those additional packages and be done with it.)
>
> Andrew said "But that's not what it's supposed to do.  The 32-bit
> libraries are built as part of the 32-bit distro."
> IIUC to get the i686 packages you need to build on i686. Rightly or
> wrongly, building on x86_64 gets you the 64bit packages, and the 32bit
> ones come from a separate repo that was built for i686, on i686.  (I
> think the glibc rpm spec file might behave the same way.)
>
> You want the spec file to be useful for a different use case, which
> while reasonable, may not be the use case the spec file was actually
> written for.  That doesn't mean the spec file is broken, it just means
> your expectations don't match what the spec file was written to do.

And just to be super clear, if all you want to do is build GCC (as
opposed to produce RPMs for a distro) then you can do it easily,
without using rpmbuild, by following the default GCC installation
instructions.

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

This is still off-topic for this list...

On 30 November 2010 14:19, Mr Dash Four wrote:
>
> 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.

The job it's designed to do is build GCC RPMs *for Fedora* in order to
distribute RPMs for Fedora. It's not necessarily meant for end users
to rebuild packages that they can just install from a repo (because
we've already established you didn't really need to build from source
anyway, you just needed to install some additional packages - and in
fact building from source *still* doesn't do what you want - even more
reason to just install those additional packages and be done with it.)

Andrew said "But that's not what it's supposed to do.  The 32-bit
libraries are built as part of the 32-bit distro."
IIUC to get the i686 packages you need to build on i686. Rightly or
wrongly, building on x86_64 gets you the 64bit packages, and the 32bit
ones come from a separate repo that was built for i686, on i686.  (I
think the glibc rpm spec file might behave the same way.)

You want the spec file to be useful for a different use case, which
while reasonable, may not be the use case the spec file was actually
written for.  That doesn't mean the spec file is broken, it just means
your expectations don't match what the spec file was written to do.

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

Re: building gcc 4.4.5 from source on Fedora 13

[Andrew Haley]

On 11/29/2010 05:21 PM, Mr Dash Four wrote:
> 
>> I'm surprised that is a dependency: you're building a cross-compiler
>> from x86-64 to i686.  The gcc build will build libgcc for all its
>> multilibs.
>>   
> When I build a cross-compiler I expect everything needed for this cross
> compiler to work and is also a part of the gcc package, regardless of
> the architecture to be compiled and the relevant rpms built. I do not
> expect to spend a whole day wondering around like headless bl**dy
> chicken solving GCC dependencies - the last time I checked this is the
> job of rpm, not me!

Sure, but with all your ranting I still haven't figured out what you
did and what went wrong.  You've just said "I build a cross-compiler"
and "I build GCC and specifically request/enable cross compiling".
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.  We
also know that there's no need to change the specfile to get the RPMs.

>> I don't think that would help.  We haven't yet established that
>> there is a bug.
>>   
> If you think that it is quite normal for me to build GCC to cross
> compile from/to i686 without compiling all other dependencies/packages
> (which are part of GCC!) on which GCC depends to function then fine - I
> disagree, however!

It is not necessary to recompile GCC in order to cross-compile from x86_64
to i686 on Fedora.  You need to install whatever 32-bit libraries you're
going to use, true.

I don't know what you did.  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.

There is clearly some mismatch of expectations, or some mistake in
procedure.

Andrew.

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

>> Ah, that bit of the output of gcc --target-help contains the assembler
>> options, though that's not made clear.
>>     
>
> This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45731
>   
Thanks, I'll add a few on my own when I have the time ;-)

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

> I'm surprised that is a dependency: you're building a cross-compiler
> from x86-64 to i686.  The gcc build will build libgcc for all its
> multilibs.
>   
When I build a cross-compiler I expect everything needed for this cross 
compiler to work and is also a part of the gcc package, regardless of 
the architecture to be compiled and the relevant rpms built. I do not 
expect to spend a whole day wondering around like headless bl**dy 
chicken solving GCC dependencies - the last time I checked this is the 
job of rpm, not me!

> I don't think that would help.  We haven't yet established that
> there is a bug.
>   
If you think that it is quite normal for me to build GCC to cross 
compile from/to i686 without compiling all other dependencies/packages 
(which are part of GCC!) on which GCC depends to function then fine - I 
disagree, however!

When I build GCC and specifically request/enable cross compiling I 
expect all GCC-related packages (and that includes packages for BOTH 
x86_64 and i686 architectures) to be compiled and built as well.

>> 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).
>>     
>
> It is a gcc package; you haven't installed it.
>
> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libstdc++.so -->
> /usr/lib/libstdc++.so.6.0.13
>  $ rpm -qf /usr/lib/libstdc++.so.6.0.13
> libstdc++-4.4.4-10.fc12.i686
>   
Why is that package not compiled then if it forms part of GCC?

The only set of packages which are compiled are all x86_64 rpms - 
nothing else! If I then proceed to install my 'cross compiler' then I am 
destined to fail because none of the i686 GCC packages on which this 
'cross compiler' is dependent are either built or installed.

In other words, when I request GCC to be compiled/built as a 
cross-compiler it is not - how on earth is that not a bug? I would 
understand and agree with your argument if I was building GCC as a 
simple compiler to function in a single-architecture system, but that is 
not the case here.

>> 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**!
>>     
>
> You surely don't expect all the legacy 32-bit stuff to be installed
> by default.
>   
They should be if GCC is dependent on it - I do not expect to see dead 
symlinks (if that is not the case why are they created then?!) after 
flawless, error-free installation of GCC on my system, so no - I at 
least expect to be informed that I need those packages and not spend a 
whole day resolving dependencies to make the bl**dy thing work, wouldn't 
you agree?

Re: building gcc 4.4.5 from source on Fedora 13

[Andrew Haley]

On 11/29/2010 01:59 PM, Mr Dash Four wrote:
> 
>>> 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).

I'm surprised that is a dependency: you're building a cross-compiler
from x86-64 to i686.  The gcc build will build libgcc for all its
multilibs.

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

I don't think that would help.  We haven't yet established that
there is a bug.

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

It is a gcc package; you haven't installed it.

/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libstdc++.so -->
/usr/lib/libstdc++.so.6.0.13
 $ rpm -qf /usr/lib/libstdc++.so.6.0.13
libstdc++-4.4.4-10.fc12.i686

> 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**!

You surely don't expect all the legacy 32-bit stuff to be installed
by default.

Andrew.

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 29 November 2010 15:06, Jonathan Wakely wrote:
>
> Ah, that bit of the output of gcc --target-help contains the assembler
> options, though that's not made clear.

This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45731

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 29 November 2010 14:49, Jonathan Wakely wrote:
> On 29 November 2010 13:59, Mr Dash Four wrote:
>>
>>> Ditto.  --32 is not a valid GCC option.
>>>
>>
>> AFAIK, it is - "gcc --help" tells me otherwise!
>
> Hmm, it's wrong
> http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#index-m32-1377

Ah, that bit of the output of gcc --target-help contains the assembler
options, though that's not made clear.  Higher up there are the
compiler options, including -m32

$ /usr/bin/gcc --target-help | fgrep 32
  -m32                        Generate 32bit i386 code
  -mcrc32                     Support code generation of crc32 instruction.
  -mpc                        Set 80387 floating-point precision (-mpc32,
  --32/--64               generate 32bit/64bit code
                           generic32, generic64
                           generic32, generic64

To use --32 you'd need to pass it to the assembler with -Wa,--32 but
that's unnecessary if you use -m32

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 29 November 2010 13:59, Mr Dash Four wrote:
>
>> Ditto.  --32 is not a valid GCC option.
>>
>
> AFAIK, it is - "gcc --help" tells me otherwise!

Hmm, it's wrong
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#index-m32-1377

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

http://fedoraproject.org/wiki/Communicate#Mailing_Lists

The users list is probably the best place to start.

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

fedoraproject.org

Fedora's bugzilla or Fedora mailing lists, or failing that, pick an
email address from the spec file.

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

> [...]
>   
> So take it up with Fedora.
>
> [...]
> That's still a Fedora issue not a GCC one.
>
> [...]
> For an authoritative reason you'd be better off asking on a Fedora list.
>
> [...]
> Fair enough, but that's still a Fedora issue, and if you want
> something in Fedora changed then this is the wrong place to suggest
> it.
>   
Do you know how/where to find the appropriate Fedora list for GCC? I'd 
love to raise the issue there and wouldn't have done it here if I knew 
that in the first place (I think I mentioned that once or twice already 
;-) )

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

On 29 November 2010 13:40, Mr Dash Four wrote:
>
>> P.S. If you just want to build GCC from source (rather than building
>> the Fedora GCC package from the Fedora GCC SRPM) then the instructions
>> are at http://gcc.gnu.org/install/
>>
>> That will not try to build java or ada, will not run the tests unless
>> you ask for it, and will build a multilib compiler by default.
>>
>
> The problem is that I wanted to build rpm, which I can use later on more
> than one machine - not just on the machine I was compiling GCC on.
>
>> That said, the default Fedora packages *are* multilib, you just needed
>> to install libgcc.i686 as Andrew pointed out.
>
> My major gripe is with the gcc.spec file provided by Fedora - it does not do
> a good job at all.

So take it up with Fedora.

> I ended up installing more packages than the one you and Andrew were kind
> enough to point out as I had a lot of dead symlinks - I wrote this in my
> previous post and thought I was pretty clear on this. Installing libgcc.i686
> along with the main GCC package does NOT solve that problem.

No, as you discovered, you also need glibc-devel.i686 to compile and
link 32-bit programs. Just like you need glibc-devel.x86_64 to compile
and link 64-bit programs.  That's still a Fedora issue not a GCC one.

> Another issue I have (had!) is that if I wanted to build GCC to be installed
> on a Fedora system using gcc.spec - provided by Fedora, no less - I expect
> at the end of this process to end up with all the necessary packages needed
> (x86_64 AND i686 if I select the multilib option) for GCC to function
> properly and with all the functionality I have requested/specified. I do not
> expect to end up with half-ars*d installation and dead links all over the
> place.
>
> If I choose to install GCC directly (without compiling it) by using
> Fedora-pre-built GCC rpm, and, as you point out, if it is already a multilib
> package, then I expect it to install all the dependencies needed for it to
> function properly and not leave me scratching my head wondering what the
> hell is going on, wouldn't you agree?

That depends on your definition of "function properly"

I can't speak for the Fedora project, but I think what you get by
default by saying "yum install gcc" is sufficient to build 64-bit
programs. The compiler itself is multilib-capable, but doesn't pull in
the other package dependencies needed to actually build 32-bit
programs. If it did, I'm sure there'd be angry users complaining that
they only want to build 64-bit, so why are 32-bit libs pulled in
unconditionally.  As it stands, users who want 64-bit-only can have it
their way and users who want both 32-bit and 64-bit can have it their
way, after installing a few extra packages.

For an authoritative reason you'd be better off asking on a Fedora list.

>> So you probably don't need to build GCC yourself anyway.
>>
>
> Aye, I've made full circle and I am still pissed off about this as I wasted
> the good part of a day figuring out what on earth is going on, which
> wouldn't have been the case if everything was installed properly by Fedora
> in the first place...and that brings me nicely to the original point I've
> made - the current package provided by Fedora isn't up to scratch and it
> leaves a lot to be desired and if someone is brave enough to compile GCC
> using the spec file provided by Fedora is going to be in a world of hurt!

Fair enough, but that's still a Fedora issue, and if you want
something in Fedora changed then this is the wrong place to suggest
it.

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

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

Re: building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

> P.S. If you just want to build GCC from source (rather than building
> the Fedora GCC package from the Fedora GCC SRPM) then the instructions
> are at http://gcc.gnu.org/install/
>
> That will not try to build java or ada, will not run the tests unless
> you ask for it, and will build a multilib compiler by default.
>   
The problem is that I wanted to build rpm, which I can use later on more 
than one machine - not just on the machine I was compiling GCC on.

> That said, the default Fedora packages *are* multilib, you just needed
> to install libgcc.i686 as Andrew pointed out.
My major gripe is with the gcc.spec file provided by Fedora - it does 
not do a good job at all.

I ended up installing more packages than the one you and Andrew were 
kind enough to point out as I had a lot of dead symlinks - I wrote this 
in my previous post and thought I was pretty clear on this. Installing 
libgcc.i686 along with the main GCC package does NOT solve that problem.

Another issue I have (had!) is that if I wanted to build GCC to be 
installed on a Fedora system using gcc.spec - provided by Fedora, no 
less - I expect at the end of this process to end up with all the 
necessary packages needed (x86_64 AND i686 if I select the multilib 
option) for GCC to function properly and with all the functionality I 
have requested/specified. I do not expect to end up with half-ars*d 
installation and dead links all over the place.

If I choose to install GCC directly (without compiling it) by using 
Fedora-pre-built GCC rpm, and, as you point out, if it is already a 
multilib package, then I expect it to install all the dependencies 
needed for it to function properly and not leave me scratching my head 
wondering what the hell is going on, wouldn't you agree?

>   Your remaining problem
> seems to be your misunderstanding that file(1) only reports 80386,
> which is the correct behaviour.
>   
Aye, I figured that one out already, thanks for pointing it out!

> So you probably don't need to build GCC yourself anyway.
>   
Aye, I've made full circle and I am still pissed off about this as I 
wasted the good part of a day figuring out what on earth is going on, 
which wouldn't have been the case if everything was installed properly 
by Fedora in the first place...and that brings me nicely to the original 
point I've made - the current package provided by Fedora isn't up to 
scratch and it leaves a lot to be desired and if someone is brave enough 
to compile GCC using the spec file provided by Fedora is going to be in 
a world of hurt!

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

P.S. If you just want to build GCC from source (rather than building
the Fedora GCC package from the Fedora GCC SRPM) then the instructions
are at http://gcc.gnu.org/install/

That will not try to build java or ada, will not run the tests unless
you ask for it, and will build a multilib compiler by default.

That said, the default Fedora packages *are* multilib, you just needed
to install libgcc.i686 as Andrew pointed out.  Your remaining problem
seems to be your misunderstanding that file(1) only reports 80386,
which is the correct behaviour.

So you probably don't need to build GCC yourself anyway.

Re: building gcc 4.4.5 from source on Fedora 13

[Jonathan Wakely]

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

You need to use -m32 otherwise you're asking for a 64-bit program
using the i686 instruction set, which is impossible.

> 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

Ditto

> 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

Ditto.  --32 is not a valid GCC option.

> 4.
> [zeek@test1 t]$ gcc -o hello -march=pentium4 -m32 hello.c

Bingo.

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

Your expectation is wrong, file(1) does not examine all instructions
in the executable to determine the minimum supported architecture.  It
only tells you it's an x86 file (as opposed to x86_64, sparc, arm or
something else.

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

> When I successfully compiled the whole GCC package (see below) the above 2 packages were not compiled/built either!

Right, glibc is a separate package to GCC, so isn't built as part of GCC.

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

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

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

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

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

> 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.  In
any case, this list is the wrong place to report problems with it.

Re: building gcc 4.4.5 from source on Fedora 13

[Andrew Haley]

On 11/26/2010 06:35 PM, Mr Dash Four wrote:
> Apologies if this is the wrong mailing list, but I could not find a
> Fedora-specific one for gcc (as my problem seems to be specific to the
> Fedora build of gcc 4.4.5 - at least that is what I think anyway)!
> 
> The reason I'd like to build gcc from source is so that I could enable
> multilib allowing me to compile code for both i686 and x86_64
> architectures (my machine is x86_64). The 'standard' Fedora distribution
> rpm does not allow me to do that - when I try "gcc -o hello -m32
> hello.c" or "gcc -o hello -march=i686 hello.c" I get the following errors:
> 
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-redhat-linux/4.4.5/libgcc_s.so when searching for
> -lgcc_s
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-redhat-linux/4.4.5/libgcc_s.so when searching for
> -lgcc_s
> /usr/bin/ld: cannot find -lgcc_s
> collect2: ld returned 1 exit status

Maybe the libgcc-4.4.5-2.fc13.i686 package isn't installed.

 sudo yum install libgcc.i686

> and
> 
> hello.c:1: error: CPU you selected does not support x86-64 instruction set
> 
> So I downloaded the source rpm and tried to build a binary rpm by
> running "rpmbuild -bb gcc.spec".
> 
> I've got a lot of errors and had to hack into this VERY POORLY designed
> file to disable the languages I do not need (gcc-java, fortran to name a
> few), but still no go!

You shouldn't get any errors.  Are you sure all the dependencies are
installed?

 sudo yum-builddep gcc

Andrew.

building gcc 4.4.5 from source on Fedora 13

[Mr Dash Four]

Apologies if this is the wrong mailing list, but I could not find a 
Fedora-specific one for gcc (as my problem seems to be specific to the 
Fedora build of gcc 4.4.5 - at least that is what I think anyway)!

The reason I'd like to build gcc from source is so that I could enable 
multilib allowing me to compile code for both i686 and x86_64 
architectures (my machine is x86_64). The 'standard' Fedora distribution 
rpm does not allow me to do that - when I try "gcc -o hello -m32 
hello.c" or "gcc -o hello -march=i686 hello.c" I get the following errors:

/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-redhat-linux/4.4.5/libgcc_s.so when searching for 
-lgcc_s
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-redhat-linux/4.4.5/libgcc_s.so when searching for 
-lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status

and

hello.c:1: error: CPU you selected does not support x86-64 instruction set

So I downloaded the source rpm and tried to build a binary rpm by 
running "rpmbuild -bb gcc.spec".

I've got a lot of errors and had to hack into this VERY POORLY designed 
file to disable the languages I do not need (gcc-java, fortran to name a 
few), but still no go!

I've passed (and fixed) the dreaded GCC No executable error, and then 
after all this (wasted about a day with this!) at my latest attempt 
after about an hour of compiling I've got this:

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.oz4CGW
+ umask 022
+ cd /home/zeek/rpmbuild/BUILD
+ '[' /home/zeek/rpmbuild/BUILDROOT/gcc-4.4.5-2.fc13.x86_64 '!=' / ']'
+ rm -rf /home/zeek/rpmbuild/BUILDROOT/gcc-4.4.5-2.fc13.x86_64
++ dirname /home/zeek/rpmbuild/BUILDROOT/gcc-4.4.5-2.fc13.x86_64
+ mkdir -p /home/zeek/rpmbuild/BUILDROOT
+ mkdir /home/zeek/rpmbuild/BUILDROOT/gcc-4.4.5-2.fc13.x86_64
+ cd gcc-4.4.5-20101113
+ LANG=C
+ export LANG
+ unset DISPLAY
+ rm -fr /home/zeek/rpmbuild/BUILDROOT/gcc-4.4.5-2.fc13.x86_64
+ cd obj-x86_64-redhat-linux
+ TARGET_PLATFORM=x86_64-redhat-linux
+ make -C x86_64-redhat-linux/libstdc++-v3
make: *** x86_64-redhat-linux/libstdc++-v3: No such file or directory.  
Stop.
error: Bad exit status from /var/tmp/rpm-tmp.oz4CGW (%install)


Close examination of the gcc.spec file reveals that the last 3 
statements above (marked with '+') are executed from the gcc.spec file 
and they refer to an environment variable called gcc_target_platform, 
which is set at the very top of gcc.spec for my host architecture 
(x86_64) to the (presumably internal) value of __target_platform. Its 
value is "x86_64-redhat-linux" as evident from the above 3 statements, 
but the actual directory name is "x86_64-unknown-linux-gnu" in reality 
and that is why this fails.

I then tried to force the issue and set the --host and --build targets 
of ./configure to "x86_64-redhat-linux", but it then ./configure assumes 
the taget directory to be "x86_64-redhat-linux-gnu", which again fails 
at the above point simply because there is no subdirectory named 
"x86_64-redhat-linux" in the "obj-x86_64-redhat-linux" directory either!

I do not wish to change the value of either the gcc_target_platform or 
__target_platform variables because they are later used to install the 
32-bit libraries under the 64 architecture and create the symlinks, 
which are used with ld and gcc itself so I am not certain that gcc/ld 
will work after that.

Any idea how can I get out of this mess?