Re: [cmake-developers] Implicit library trouble with mixed languages
On 5/3/2017 5:25 PM, Brad King wrote: > On 05/02/2017 05:47 PM, Christian Pfeiffer wrote: >> Before filtering, gcc's output gives me the libgcc and libgcc_s twice. > I think we already de-duplicate the results after extraction. This only happens for the implicit library directories and frameworks directories. The libraries themselves aren't de-duplicated, most likely to prevent causing link errors in cases where some multiplicity is needed. On it's own this isn't harmful though, so I've opened an MR removing gcc entirely from the filter line. > >> However, I was mainly asking because the general matching logic there >> can break down in other ways, too. For example, filtering libclang_rt.* >> will cause Clang builds that pull in sanitizers, e.g. memory sanitizer >> or UBsan, which both require libclang_rt.msan-... and >> libclang_tr.ubsan_... to be linked to break on e.g. Linux. > That was added for this: > > * https://gitlab.kitware.com/cmake/cmake/issues/16194 > * https://gitlab.kitware.com/cmake/cmake/merge_requests/37 I see, thanks. In this case it's certainly better to keep it in there. > Thanks, > -Brad Thanks, Chris -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Implicit library trouble with mixed languages
On 05/02/2017 05:47 PM, Christian Pfeiffer wrote: > Before filtering, gcc's output gives me the libgcc and libgcc_s twice. I think we already de-duplicate the results after extraction. > However, I was mainly asking because the general matching logic there > can break down in other ways, too. For example, filtering libclang_rt.* > will cause Clang builds that pull in sanitizers, e.g. memory sanitizer > or UBsan, which both require libclang_rt.msan-... and > libclang_tr.ubsan_... to be linked to break on e.g. Linux. That was added for this: * https://gitlab.kitware.com/cmake/cmake/issues/16194 * https://gitlab.kitware.com/cmake/cmake/merge_requests/37 Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Implicit library trouble with mixed languages
On 5/2/2017 6:52 PM, Brad King wrote: > On 05/02/2017 11:48 AM, Christian Pfeiffer wrote: >> turn depends on libgcc_s. Any library starting with 'gcc' is being >> ignored in CMakeParseImplicitLinkInfo.cmake L.136, so libgcc_s is being >> stripped from the commandline. PGI Fortran however does not need >> libgcc_s on its own and therefore won't link it. > You might be able to just remove `|gcc.*` from the regex. > The comment nearby says it is trying to remove libraries that > are expected to be common to all language toolchains, but that > is not the case for GCC's libraries when mixing vendors. It > may not be necessary to remove `gcc_s` even when all the tools > are GNU-based (e.g. gcc/g++/gfortran) because we only explicitly > link to implicit libraries for other languages that are not also > implicit to the link language. > > -Brad > I think it has been done to prevent libgcc(_s) from appearing very often in the link line. Before filtering, gcc's output gives me the libgcc and libgcc_s twice. PGI also has libgcc appearing numerous times (but not libgcc_s), once after every compiler support library it links itself. I think virtually every compiler uses libgcc, so my idea would have been to change the regex for GCC to gcc[^_].* However, I was mainly asking because the general matching logic there can break down in other ways, too. For example, filtering libclang_rt.* will cause Clang builds that pull in sanitizers, e.g. memory sanitizer or UBsan, which both require libclang_rt.msan-... and libclang_tr.ubsan_... to be linked to break on e.g. Linux. This can be reproduced by using a C and CXX file, the C one built with CMAKE_C_FLAGS set to -fsanitize=memory and the CXX one without. I'm not sure how useful such a binary might be, but it's definitely a possible option to build it like that. (I'm not quite sure why libclang_rt would make sense on that list, though. Is this because of OSX?) It might be sufficient to change the GCC regex as above and the clang_rt one somehow (I'm not sure what it's supposed to filter, so I don't know how it would make sense). - Chris -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Implicit library trouble with mixed languages
On 05/02/2017 11:48 AM, Christian Pfeiffer wrote: > turn depends on libgcc_s. Any library starting with 'gcc' is being > ignored in CMakeParseImplicitLinkInfo.cmake L.136, so libgcc_s is being > stripped from the commandline. PGI Fortran however does not need > libgcc_s on its own and therefore won't link it. You might be able to just remove `|gcc.*` from the regex. The comment nearby says it is trying to remove libraries that are expected to be common to all language toolchains, but that is not the case for GCC's libraries when mixing vendors. It may not be necessary to remove `gcc_s` even when all the tools are GNU-based (e.g. gcc/g++/gfortran) because we only explicitly link to implicit libraries for other languages that are not also implicit to the link language. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Implicit library trouble with mixed languages
Hi folks, I've tried to link some code built with GNU G++ together with the PGI Fortran compiler as linker. However, G++ pulls in libstdc++, which in turn depends on libgcc_s. Any library starting with 'gcc' is being ignored in CMakeParseImplicitLinkInfo.cmake L.136, so libgcc_s is being stripped from the commandline. PGI Fortran however does not need libgcc_s on its own and therefore won't link it. Alas, by stripping libgcc_s from the implicit library list, the linking process fails due to missing symbols. On a side note, PGI C also doesn't use libgcc_s, only PGI C++ does. In fact, using an all PGI environment yields the same issue. I'd like to open an MR for this issue, but I'm not quite sure how to perform the cleanup as it exists right now in a fashion that doesn't include too many language-specific items on the link line - the reason this removal process exists - but yet works in a robust fashion. Ideally, we'd compare all enabled languages and strip the libraries that are being linked by all, but given the way that enable_language() can be called anywhere, that doesn't seem to lead to a solution to me. Any suggestions on how to handle/fix the issue? - Chris -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
