George Vasick <George.Vasick at Sun.COM> writes:
>> I never assumed otherwise. Even so, it may be an option to have only a
>> single package delivering libstdc++.so.6 and (say) libstdc++.so.7
>> instead of splitting, just like the Studio compilers deliver all major
>> versions of libF77.so in SPROl77sx. I don't really think users know
>> (and care) about specific shared library to be installed separately.
>
> OK, now I get what you mean.
>
> I proposed suffixing the library package names with their major versions
> to better manage both new libraries coming in and old libraries going
> away. Maintaining a single package for all major versions of a library
> would potentially force users to install multiple version of a library
> even if they are sticking to a single version of GCC.
True, but if you do otherwise, you force users to know which version is
which, which can be difficult.
> I don't have a strong opinion on this and will make the change.
Great, thanks.
>>> Issue 2:
>>> It's obvious you're including gccfss, but what are the consequences? Do
>>> you replace the GCC SPARC backend by the Sun backend here? This may not be
>>> appropriate, since this heavily deviates from the upstream FSF GCC, and may
>>> cause problems. Have you run the GCC testsuite this way and compared the
>>> results to those with the GCC backend? I think it should be possible for
>>> the user to select between gccfss and the regular GCC backend here.
>>>
>>> Response:
>>> We provide both the GCC backend and the Sun backend. We include the GCC
>>> testsuite in our testing of the Sun backend. The user is able to invoke
>>> the GCC backend under flag control.
>>
>> How does this work (i.e. which flags are used), and what is the default?
>
> The default is the Sun backend and the flag to override is -frtl-backend.
I don't really think this is wise: while it may produce better code in
some (or even most) cases, this is not what uses expect when thy run
GCC, though I'm not sure about the downsides. It might happen that,
should problems show up, bugs are reported to the GCC project which
cannot do anything about them.
>> From the file list, it seems like you will be integrating GCC 4.3.3?
>> Why not go straight to the latest 4.3 release, 4.3.4?
>
> Just lead time at this point. Since this packaging corrects issues with
> the 432 release, I want to get it out sooner instead of later.
Understood, although I don't expect to be any differences between 4.3.3
and 4.3.4 builds. I don't feel strongly about this, but I'd consider it
prudent to integrate the most current version to avoid having to deal
with bugs that are already fixed upstream.
>>> Exported Interfaces Comments
>>> =================== ========
>>> SUNWgcc43 GCC 4.3.X package.
>>> All interfaces Uncommitted.
>>>
>>> usr/gcc/4.3/lib/<mach64>/libobjc_gc.so=../../../../lib/<mach64>/libobjc_gc.so.2
>>
>> You seem to be configuring GCC with --enable-objc-gc, which is not the
>> default? Why?
>
> Correct. It is optional under flag control to the gcc command. Is
> there a reason we should not provide this feature to our users?
First of all, I think all non-default configure options need
justification in some way. But there seems to be no harm done in this
case: it just adds an additional library and doesn't change anything
else.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
