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
