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

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
> 

Reply via email to