Clang static linking #15
Conversation
The previous logic always threw away stdout if anything was present on stderr. But we sometimes need the contents of stdout despite there also being a nonempty stderr. For backwards compatibility, this change leaves the behavior of getOutput() alone, while adding getStdout() and getStderr() methods for situations when more specifics are necessary.
This method provides a way to easily execute a command while returning the CaptureStreamHandler that was used to capture the output. This provides a more flexible alternative to CaptureStreamHandler#run, which returns only stderr or stdout contingent on whether stderr is nonempty. Unfortunately, that mechanism left no way to interrogate stdout in the case of a nonempty stderr. In contrast to run, The execute method returns the CaptureStreamHandler itself, so that both stderr and stdout can be freely accessed.
OS X 10.9 Mavericks now uses LLVM with clang by default. While it pretends to be gcc, there are a few incompatibilities. In particular, the -static-libgcc and -shared-libgcc flags are unsupported, and -lstdc++-static does not work because that static library is not present on standard include paths.
|
NAR plugin for Maven » cpptasks-parallel #9 SUCCESS |
|
We almost certainly need PR #14 first, and then some additional changes to the clang configuration, rather than the hacky solution of this PR. Anyone else less clueless about cpptasks-parallel care to comment? |
|
DEV@cloud: Can one of the admins verify this patch? |
|
Well, it seems that your approach was pretty good and my suggestion was not so. Could you please have a look at https://github.com/maven-nar/cpptasks-parallel/compare/clang and tell me whether that is okay...? |
|
@ctrueden did you have a chance to test yet? |
|
It "works" (i.e., BUILD SUCCESS) but as I feared, the resultant library is not actually statically linked with So I vote that we simply punt: issue a warning stating that the resultant binary will not actually be statically linked in this circumstance, and keep my hack above since it at least makes the build succeed. |
|
Caused by: D:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\cl failed with return code 2 Anyone knows how to solve the problem? |
|
@kangyz Shouldn't you be posting this as a new issue? |
On OS X 10.9 Mavericks, LLVM with clang is now used. This branch adds case logic to the
GppLinkerimplementation to handle clang's incompatibilities with gcc, notably the unsupported-static-libgccand-shared-libgccflags.I am far from a C++ expert, so would appreciate code review here. In particular, I suspect that simply suppressing the
-lstdc++-staticflag is the wrong solution. (10.9 also uses libc++ instead of libstdc++ now; but-lc++-staticalso doesn't work...)Note that the first three commits are merely to support the new
isClang()method ofGppLinker, which needs to call out tog++ --versionto check that. TheCaptureStreamHandlerpreviously had an annoying limitation whereCaptureStreamHandler.runwould return only stderr if it was nonempty—andg++ --versionhappens to return a mixture of stderr and stdout. So now theexecutemethod provides a way to request stdout specifically, which is what we need here.