Re: /bzr/squid3/trunk/ r10096: Bug 2778: fix linking issues using SunCC

[Amos Jeffries-2]

Francesco Chemolli wrote:

> ------------------------------------------------------------
> revno: 10096
> committer: Francesco Chemolli <kinkie@...>
> branch nick: trunk
> timestamp: Fri 2009-11-06 17:22:16 +0100
> message:
>   Bug 2778: fix linking issues using SunCC
>  
>   SunCC doesn't handle inline extern functions, and misses some duplicate
>   code detection features gcc has; as a result squid-specific operator new and
>   operator delete get defined multiple times and fail linking.
>   Implemented a compiler-specific workaround by de-inlining the code.
>   Improved Solaris OS detection logic (and dropped _SQUID_SUNOS_ which was not
>   used anyways)
> modified:
>   compat/compat.h
>   compat/os/solaris.h
>   compat/osdetect.h
>   include/SquidNew.h
>   src/SquidNew.cc
>

Oops. _SQUID_SUNOS_ is used.   _SQUID_SUN_ was the unused one.

Please also revert the bit changing compat/compat.h. It's not relevant.

Also, were the added 1's in osdetect.h actually required? There may be
many other places in the code hitting the same problem if so.
(I'm now converting my old pre-compiler test app into unit-tests so we
can easily identify this)

Amos
--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.14

[Kinkie]

Ok, I will asap.
Regarding the #defines: autoconf does it, so it's probably the most
portable way, and it doesn't hurt anyways.
I wouldn't go as far as defining this in a style guide, but converting
stuff as it is touched may help portability-wise.
the first input to me to do this was because sun cpp complained about
non-constant symbols as I converted from #ifdef to #if. It was not the
root cause, but I decided to let it in for the above reasons.

On 11/7/09, Amos Jeffries <squid3@...> wrote:

> Francesco Chemolli wrote:
>> ------------------------------------------------------------
>> revno: 10096
>> committer: Francesco Chemolli <kinkie@...>
>> branch nick: trunk
>> timestamp: Fri 2009-11-06 17:22:16 +0100
>> message:
>>   Bug 2778: fix linking issues using SunCC
>>
>>   SunCC doesn't handle inline extern functions, and misses some duplicate
>>   code detection features gcc has; as a result squid-specific operator new
>> and
>>   operator delete get defined multiple times and fail linking.
>>   Implemented a compiler-specific workaround by de-inlining the code.
>>   Improved Solaris OS detection logic (and dropped _SQUID_SUNOS_ which was
>> not
>>   used anyways)
>> modified:
>>   compat/compat.h
>>   compat/os/solaris.h
>>   compat/osdetect.h
>>   include/SquidNew.h
>>   src/SquidNew.cc
>>
>
> Oops. _SQUID_SUNOS_ is used.   _SQUID_SUN_ was the unused one.
>
> Please also revert the bit changing compat/compat.h. It's not relevant.
>
> Also, were the added 1's in osdetect.h actually required? There may be
> many other places in the code hitting the same problem if so.
> (I'm now converting my old pre-compiler test app into unit-tests so we
> can easily identify this)
>
> Amos
> --
> Please be using
>    Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
>    Current Beta Squid 3.1.0.14
>

--
    /kinkie

[Amos Jeffries-2]

Kinkie wrote:
> Ok, I will asap.
> Regarding the #defines: autoconf does it, so it's probably the most
> portable way, and it doesn't hurt anyways.
> I wouldn't go as far as defining this in a style guide, but converting
> stuff as it is touched may help portability-wise.
> the first input to me to do this was because sun cpp complained about
> non-constant symbols as I converted from #ifdef to #if. It was not the
> root cause, but I decided to let it in for the above reasons.

Nevermind.  Halfway through the unit-tests to check for viability I
re-discovered we do indeed have to define to one, zero, or undefined for
#if to work.

Amos

>
> On 11/7/09, Amos Jeffries <squid3@...> wrote:
>> Francesco Chemolli wrote:
>>> ------------------------------------------------------------
>>> revno: 10096
>>> committer: Francesco Chemolli <kinkie@...>
>>> branch nick: trunk
>>> timestamp: Fri 2009-11-06 17:22:16 +0100
>>> message:
>>>   Bug 2778: fix linking issues using SunCC
>>>
>>>   SunCC doesn't handle inline extern functions, and misses some duplicate
>>>   code detection features gcc has; as a result squid-specific operator new
>>> and
>>>   operator delete get defined multiple times and fail linking.
>>>   Implemented a compiler-specific workaround by de-inlining the code.
>>>   Improved Solaris OS detection logic (and dropped _SQUID_SUNOS_ which was
>>> not
>>>   used anyways)
>>> modified:
>>>   compat/compat.h
>>>   compat/os/solaris.h
>>>   compat/osdetect.h
>>>   include/SquidNew.h
>>>   src/SquidNew.cc
>>>
>> Oops. _SQUID_SUNOS_ is used.   _SQUID_SUN_ was the unused one.
>>
>> Please also revert the bit changing compat/compat.h. It's not relevant.
>>
>> Also, were the added 1's in osdetect.h actually required? There may be
>> many other places in the code hitting the same problem if so.
>> (I'm now converting my old pre-compiler test app into unit-tests so we
>> can easily identify this)
>>
>> Amos
>> --
>> Please be using
>>    Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
>>    Current Beta Squid 3.1.0.14
>>
>
>

--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.14

[Kinkie]

On Sat, Nov 7, 2009 at 2:27 AM, Amos Jeffries <squid3@...> wrote:

> Francesco Chemolli wrote:
>>
>> ------------------------------------------------------------
>> revno: 10096
>> committer: Francesco Chemolli <kinkie@...>
>> branch nick: trunk
>> timestamp: Fri 2009-11-06 17:22:16 +0100
>> message:
>>  Bug 2778: fix linking issues using SunCC
>>    SunCC doesn't handle inline extern functions, and misses some duplicate
>>  code detection features gcc has; as a result squid-specific operator new
>> and
>>  operator delete get defined multiple times and fail linking.
>>  Implemented a compiler-specific workaround by de-inlining the code.
>>  Improved Solaris OS detection logic (and dropped _SQUID_SUNOS_ which was
>> not
>>  used anyways)
>> modified:
>>  compat/compat.h
>>  compat/os/solaris.h
>>  compat/osdetect.h
>>  include/SquidNew.h
>>  src/SquidNew.cc
>>
>
> Oops. _SQUID_SUNOS_ is used.   _SQUID_SUN_ was the unused one.

Done in revno 10104.
as an aside, does it really matter to support SunOS nowadays? The last
release dates back to 1994, I'd be surprised if ANY kind of surviving
hardware would still support it (but un-supporting the platform is a
different project).

--
    /kinkie

[Amos Jeffries-2]

On Tue, 10 Nov 2009 15:47:22 +0100, Kinkie <gkinkie@...> wrote:
> On Sat, Nov 7, 2009 at 2:27 AM, Amos Jeffries <squid3@...>
wrote:

>> Francesco Chemolli wrote:
>>>
>>> ------------------------------------------------------------
>>> revno: 10096
>>> committer: Francesco Chemolli <kinkie@...>
>>> branch nick: trunk
>>> timestamp: Fri 2009-11-06 17:22:16 +0100
>>> message:
>>>  Bug 2778: fix linking issues using SunCC
>>>    SunCC doesn't handle inline extern functions, and misses some
>>> duplicate
>>>  code detection features gcc has; as a result squid-specific operator
>>> new
>>> and
>>>  operator delete get defined multiple times and fail linking.
>>>  Implemented a compiler-specific workaround by de-inlining the code.
>>>  Improved Solaris OS detection logic (and dropped _SQUID_SUNOS_ which
>>> was
>>> not
>>>  used anyways)
>>> modified:
>>>  compat/compat.h
>>>  compat/os/solaris.h
>>>  compat/osdetect.h
>>>  include/SquidNew.h
>>>  src/SquidNew.cc
>>>
>>
>> Oops. _SQUID_SUNOS_ is used.   _SQUID_SUN_ was the unused one.
>
> Done in revno 10104.
> as an aside, does it really matter to support SunOS nowadays? The last
> release dates back to 1994, I'd be surprised if ANY kind of surviving
> hardware would still support it (but un-supporting the platform is a
> different project).

Worth a query to squid-users. Any OS which is so old it does not support
the auto-tools and libraries we now need is a candidate. I'm thinking
NextStep may be one more.
Though I'm inclined to keep as much support as possible until we have
solid evidence the OS is not able to ever be build Squid.

Amos

[Henrik Nordstrom-5]

ons 2009-11-11 klockan 10:38 +1300 skrev Amos Jeffries:

> Worth a query to squid-users. Any OS which is so old it does not support
> the auto-tools and libraries we now need is a candidate. I'm thinking
> NextStep may be one more.
> Though I'm inclined to keep as much support as possible until we have
> solid evidence the OS is not able to ever be build Squid.

There probably is one or two that may try running Squid on something
that once upon a time was Solaris 1.x (known as SunOS 4.x before the
name switch to Solaris for everything). But in general terms that OS is
pretty much distinct these days. Been declared end-of-life for more than
a decade now, with last release in 1994.

autotools has never been part of SunOS for that matter, always an addon.
And someone patient enough can get up to date autotools + gcc + whatever
ontop of SunOS 4.x and build Squid. Question is will anyone really do
that?

Regards
Henrik