[csw-maintainers] GCC 4.6 progress

[Peter FELECAN]

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?

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