hg: ppc-aix-port/jdk7u/jdk: Updated using pthreads in java_md_solinux.c to just rely on USE_PTHREADS. Removed the superflous __linux__ as USE_PTHREADS is already explictly turned on for linux builds

[Thomas Stüfe]

Hi, Neil, Volker,

I also looked and did not find any proof that CPPFLAGS would *not* be
synonymous for C++ on AIX. So, Neil may be right with his AIX claim.

The "hardest" definition I could find (beside wikipedia) is the GNU make manual:

http://www.gnu.org/software/make/manual/make.html#Implicit-Variables

I think in the end it is just our decision - as Volker said, the make
does not seem to use implicit rules but always spells them out. It
would be my preference to stick to the GNU standard, but I am pretty
sure it is already used both ways in the OpenJDK make files.

Regards,
Thomas


On Wed, Jul 18, 2012 at 4:19 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> I think the build (at least the HotSpot build) doesn't use implicit
> rules at all.
> I have no reference for this, but we recently found out that we can
> considerably speed up the Windows build if we disable implicit make
> rules, so this implicates that they are not really  used.
>
> Regards,
> Volker
>
> On Wed, Jul 18, 2012 at 1:58 PM, Neil Richards <neil.richards at ngmr.net> wrote:
>> On Tue, 2012-07-17 at 08:21 +0200, Thomas Stüfe wrote:
>>> Hi Neil,
>>>
>>> >
>>> > On AIX, CPPFLAGS is used for invocations of the C++ compiler (the 'PP'
>>> > standing for 'Plus-Plus').
>>> >
>>> > On Linux, CPPFLAGS is for the C Pre-Processor, and so is used for
>>> > invocations of both the C and C++ compilers.
>>> > (Linux has CXXFLAGS for C++-specific options).
>>> >
>>> > So, on Linux, adding to CPPFLAGS_COMMON should cater for both scenarios,
>>> > I believe, whilst on AIX, one needs to add to both CPPFLAGS_COMMON and
>>> > CFLAGS_COMMON.
>>>
>>> Are you sure this is right? I could not find any documentation for
>>> that, e.g. on the xlC manuals.
>>>
>>> Reason I ask is I always thought both CXXFLAGS and CPPFLAGS originally
>>> came from the GNU automake toolchain, and that what you describe as
>>> "the Linux way" is just the correct way to use those variables - but
>>> that many people use CPPFLAGS as "C++-Flags" because that is the first
>>> thing which comes to mind.
>>>
>>> I may be wrong. I think it's mostly all convention anyway, the only
>>> tools I think do something with those variables are autoconf/automake.
>>>
>>> When working on the AIX port of the SAP JVM, we tried to keep the GNU
>>> meaning of CPPFLAGS intact: CPPFLAGS for -D../-I.., CXXFLAGS/CFLAGS
>>> for languange specific settings. However, this has the tendency to
>>> detoriate, so you probably will find both meanings in the makefiles.
>>>
>>> Kind Regards,
>>> Thomas Stuefe
>>> SAP Germany
>>>
>>
>> Hi Thomas,
>> To be honest, I'm more certain on the Linux side of this story than I am
>> on the AIX side. :-)
>>
>> When writing the reply, I did find some references via Google that
>> seemed to confirm the AIX story I was spinning. Naturally, as I didn't
>> take a note of them at that point, trying to track those references down
>> again has proven elusive, thus casting doubt on their validity.
>>
>> Obviously, the use of these variables is controlled by the make
>> environment, rather than the compiler, as it is the (potentially
>> implicit) rules in the make system that use the variables (in whatever
>> combination) to give command line options to the compiler.
>>
>> So, if/as it's GNU make being used on both systems, I suppose it makes
>> sense its behaviour re. these variables should also be (made to be)
>> similar.
>>
>> If this is  the case, I'm hoping I'll see duplication of
>> (-DUSE_PTHREADS) options when compiling C++ code (with Steve's change)
>> on AIX. If I see that, I'll have confirmation as to what correction to
>> Steve's change is necessary to bring the use of these variables into
>> line (with the GNU make / autoconf / automake) norm.
>>
>> If that option isn't duplicated in the invocation of the C++ compiler on
>> AIX, it may suggest there are other factors in play (eg. the implicit
>> rule for C++ compilation is being overridden somewhere). In that case,
>> I'll have to dig deeper to figure out what's going on.
>>
>> Regards,
>> Neil
>>
>> --
>> Unless stated above:
>> IBM email: neil_richards at uk.ibm.com
>> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>