On 2019-02-15 14:30, Baesken, Matthias wrote:
Are they both pointing to the same binary, and the mode of operation
(legacy xlc vs xlclang) is determined by the name of the executable?
Hello, in the installation I use I have separate binaries .
Is xlclang++ always available for version 16+ of xlc?
I think so, as least I am not aware of an installation mode with separate
binaries .
However I am not an XLC installation guru 😊 .
If so, maybe we should just make sure we call the compiler with the
correct name if version 16+ is detected?
I thought that we currently first set the toolchain name and then set a
fix name for the binary and check the version .
But I might be wrong. Maybe we need to adjust this .
Or just at some future point in time declare xlc16 as minimum
requirement (this makes things easier , we can then use the new binary names
).
Yeah, we can adjust the process if needed. And to solve this *properly*,
we should. I still think this looks like the wrong way to do it. But...
If we're talking about a short migration story, where soon XLC 16 will
be required, and we can just replace
TOOLCHAIN_CC_BINARY_xlc="xlc_r"
with
TOOLCHAIN_CC_BINARY_xlc="xlclang"
then I can accept it anyway, so we don't need to complicate things.
I also don't like how xlclang is just run from the path, but OTOH it's
only you guys who are going to run that in practice, and it's just going
to be temporary, so, whatever.
The name AIX_USE_CLANG is not really correct, though. This is not about
AIX. It should be XLC_USE_CLANG (or maybe better XLC_USES_CLANG, even
perhaps XLC_IS_CLANG?!). And, as I said, it should use true/false, not 0/1.
If you fix this, and we agree that this is a temporary measure, I'm OK
with the patch.
/Magnus
Best regards, Matthias
-----Original Message-----
From: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>
Sent: Freitag, 15. Februar 2019 13:32
To: Baesken, Matthias <matthias.baes...@sap.com>; 'build-
d...@openjdk.java.net' <build-dev@openjdk.java.net>
Cc: Doerr, Martin <martin.do...@sap.com>
Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection
On 2019-02-15 12:53, Baesken, Matthias wrote:
Hi Magnus,
we are currently able to build (+ test 😊 ) jdk/jdk on AIX with the
xlclang++ based build .
Only needed are this change ,
plus a one-liner in harfhuzz is needed (we try to get this upstream into
harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the
mid/far
future , I would add this one liner to my patch).
So I hope that there will be not so many follow ups (but you never know
).
Ok, that's good to hear.
If so, could the choice between -g ang -g1 be handled with the normal
TOOLCHAIN_CHECK_COMPILER_VERSION?
I'll look into this . Unfortunately the version output is the same for
both
frontends :
New one:
bash-4.4$ xlclang++ -qversion
IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string)
Version: 16.01.0000.0001
Legacy xlc:
bash-4.4$ xlC_r -qversion
IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string)
Version: 16.01.0000.0001
(and some-strange-hex-string is the same for both)
Hm.
Are they both pointing to the same binary, and the mode of operation
(legacy xlc vs xlclang) is determined by the name of the executable?
Is xlclang++ always available for version 16+ of xlc?
If so, maybe we should just make sure we call the compiler with the
correct name if version 16+ is detected?
Or is there a way to force xlclang mode using a flag?
/Magnus
