Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
AIX XL C/C++ V16.1 comes with clang/clang++ but is not fully clang compatible #3474
I did this
IBM quite recently released Xl C/C++ V16.1 for AIX (see announcement). This compiler comprises the 'good old' known xlc (and variants) C-compiler, but this product now also contains xlclang and xlclang++. Apparently, support for newer standards like C11/C++11/C++14 is not added to XL C/C++ but to xlclang (C) or xlclang++ (C++). The xlclang compiler supports some/most of the clang compiler but not all. When calling configure with the following flags:
(with xlclang in the PATH, /opt/IBM/xlC/16.1.0/bin/xlclang)
I then get a configure result that adds -Qunused flag. See (part of) configure output:
Unfortunately, the -Qunused flag is not supported by IBM's xlclang, see:
See also the compiler reference manual at compiler ref
I expected the following
I'm not sure how to fix this. It is probably easy to adjust configure in such way that -Qunused is not added if $CC maches xlclang. In that case, this option can be omitted. However, I don't know the procedure 'how to add support for a new compiler'.
Because I'm building a static libcurl, I don't really suffer from this issue. That may probably change for people who like to build a shared library. In that case, the linker is invoked with incorrect options.
I would be nice if configure fully recognizes AIX's xlclang and passes correct compiler flags to it.
A similar/related thing is another compiler option that does not work correctly (but does not raise further errors):
I think that _xl_clang is probably more XL than clang. Please refer to IBM's compiler reference documentation for more information about what options are supported.
In case if greater details are wanted, test or something else, feel free to ask. If wanted, I can upload configure related files.
[curl -V output]
AIX 7.1 TL4
Please try out my patch in #3476. It should at least fix the use of the non-supported option.
Many thanks for very quick reply. I've updated the m4/curl-compilers.m4 with the modified file and reran configure (clean/from scratch).
I still get (part from config.log):
When I start the build, I get:
In the output of configure, the following line still exists:
Attached: config.log, config.status and the output of the configure command (all in onze tar.gz file).
Sorry, please forgive my innocence. Unfortunately, autoconf was not installed. I've obtained it from the AIX (Linux) Toolbox (including automake). But finally I stuck down on libtoolize. It is not in the AIX Toolbox (repositories). I will trust you on this fix and will await until it will be released in a next cURL release. For now, it is just a warning that does apparently not harm now.
I've downloaded the snapshot from https://curl.haxx.se/snapshots/ (taken 16. January download).
Configure still says:
As a result, still messages about the -Qunused option passed to ld are being displayed.
Also some confusing (but it is no error, just an observation) output my still be produced by configure:
I..e. I did not expect that error message are part of the output. The job of configure is finding out the compiler and OS capabilities, but if something does not exist, it should not be reported as error. I did not figure out in detail whether a wrong call to the compiler was done or whether some stderr output was not suppressed. IBM AIX works slightly different in making a shared library (for xlc). For xlclang, they both support the -qmkshrobj as well as the -shared option.
I double cheched m4/curl-compilers.m4 and configure; both contain a line about if xlclang. See attachment for more details.
and reading the documentation again I see that
Do you work 24h a day?? Thanks for very quick reply.
I guess you've found the ref
Output of configure is now (copied some parts):
The second part is ok. The first part is up to you to decide to do something with.
I think this is doing the right thing. It only checks for xlclang if it first found the clang variable, which I hope won't happen in the regular xlc case.
Thanks for verifying the update. I'll merge that into master.