[csw-maintainers] GCC 4.6 progress

[Maciej Bliziński]

2011/8/15 Peter FELECAN <pfelecan at opencsw.org>:
> Maciej Bliziński <maciej at opencsw.org> writes:
>
>> 2011/8/15 Peter FELECAN <pfelecan at opencsw.org>:
>>> Maciej Bliziński <maciej at opencsw.org> writes:
>>>
>>>> 2011/8/14 Maciej Bliziński <maciej at opencsw.org>:
>>>>> ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory
>>>>> ld: fatal: File processing errors. No output written to
>>>>> .libs/liblto_plugin.so.0.0.0
>>>>>
>>>>> Does anyone have an idea where to look for diagnostic information?
>>>>
>>>> If anyone wants reproduce the problem, all code is committed and
>>>> available in pkg/gcc4/branches/bootstrap-4.6.
>>>
>>> Are you trying to build with Sun's C compiler? (I never succeeded to build
>>> gcc with that compiler) In the affirmative you'll have a heavy time
>>> generating the Ada compiler.
>>
>> Yes, I am trying to get the stage 1 gcc built with Sun Studio. I've
>> found a proof of concept how to work around the libtool problem above,
>> but it's not the proper fix yet.
>>
>> Dago got the 4.3.6 version to build.  Built packages generate a ton of
>> checkpkg errors, such as sparcv8+ binaries and file conflicts.  It
>> will take a while to clean all that up.
>
> And how did you generate the Ada compiler?

For 4.3.6, it built fine.  The 4.6.1 version requires the PPL library,
which I got to compile for sparc, but not for i386, so I did not
attempt to build Ada for 4.6.1.  When you were working on it, did you
also got stuck on PPL?

Meanwhile, I talked with Dago on IRC; Dago took a look at PPL and
stamped out compilation errors in PPL.

>> In general, I find the existing gcc recipe very complex and I'll see
>> if I can simplify it.
>
> Complex package, complex recipe.
>
>> I have a question: What is the rationale behind having the gcc package
>> split off to so many subpackages? I understand splitting off packages
>> with the shared libraries, this is required to make the catalog
>> maintainable. But all the specific compilers? It can't be the disk
>> space argument, because if you have a development machine, you need to
>> have a lot of disk space anyway. What is it then? If there is no
>> really good reason, I would be inclined to switching gcc to a single
>> package + shared libraries -- this way its maintenance will be much
>> easier.
>
> non exhaustive reasons for which the packaging is done that way:
>
> 1. no need to install all the compilers when one needs only 1 language
>
> 2. traditional packaging on all the platforms that I know is done this
>   way
>
> 3. there are common components which are not libraries
>
> The disk space is not an argument in our case but it is in other cases.
>
> Unfortunately you'll end up with more packages than the current ones and
> in my opinion that it's not a bad thing. Good granularity is a quality
> factor for our project.

Fair enough, I'll slice the package separating out language-dependent
files into subpackages.  The main difference in packaging between the
previous and the new gcc packages will be that I'm putting the shared
libraries into /opt/csw/lib and creating library-specific packages,
conforming to our packaging policy.  There is one issue, in which
gcc3corert and gcc3g++rt try to deliver the same files, so we need to
repackage them in a way that makes room for gcc4 shared libs.

Maciej