Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH
On Fri, Jul 21, 2023 at 2:37 PM Brad King wrote: > The behavior change came from this CMake merge request: > * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538 > because the distutils variant is deprecated. This is now under discussion in an upstream CMake issue: * https://gitlab.kitware.com/cmake/cmake/-/issues/25113 Thanks, -Brad
Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH
On Fri, Jul 21, 2023 at 11:21 AM Sebastiaan Couwenberg wrote: > On bookworm distutils is still used which returns: ... > On sid sysconfig is used which results: The behavior change came from this CMake merge request: * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538 because the distutils variant is deprecated. > To get the right path for the Debian python3 interpreter, > you need to add 'deb_system': With distutils a generic `plat_specific=True` option was enough to get each platform's preferred behavior. Does every client of Python's sysconfig need to have a big dispatch block that looks up the host platform and memorizes platform-specific arguments? A similar concern was raised here: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998739#22 but never resolved. As a side note, adding `DEB_PYTHON_INSTALL_LAYOUT=deb` to the environment resolves this locally. -Brad
Bug#959064: ignition-transport FTBFS in testing.
On 4/29/2020 10:40 PM, peter green wrote: The behavior of pkg-config has changed This lets though a -isystem parameter with a space which was previously suppressed And the space in said parameter breaks cmake. I think cmake should handle -isystem¹ and as this is reproducible without ignition-transport, I'm reassigning this to cmake. This certainly seems like the long term solution. This has been reported to CMake upstream: * PkgConfig chokes with `-isystem` with pkg-config 0.29.2 https://gitlab.kitware.com/cmake/cmake/-/issues/20652 -Brad
Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build
On 12/7/18 7:44 AM, Jochen Sprickerhof wrote: >> Both are valid ways to link to the pthread library, which is all >> the `-pthread` flag does when used to drive linking. > > I don't agree. Quoting from my mail: > > "Define additional macros required" Macros are for compiling. It is not used during linking. Either way, `-lfoo` can appear for other libraries and ros-catkin needs the fix. -Brad
Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build
On 12/6/18 4:16 PM, Jochen Sprickerhof wrote: > after reading up on this, I think this needs fixing in cmake. > > So neither adding -lpthread, > nor adding /usr/lib/x86_64-linux-gnu/libpthread.so > seems correct to me. Both are valid ways to link to the pthread library, which is all the `-pthread` flag does when used to drive linking. > I will revert the workaround in ros-catkin if you agree. The patch here: http://launchpadlibrarian.net/399812910/ros-catkin_0.7.14-7_0.7.14-7ubuntu1.diff.gz is not a workaround. The input to that logic could contain -lfoo generated by other means for other libraries. This case just happened to expose the existing bug in that logic. Actually looking at the applied fix https://sources.debian.org/src/ros-catkin/0.7.14-8/cmake/templates/pkgConfig.cmake.in/#L118 that logic may need additional work to handle plain `-pthread` or other link flags. > [FindThreads] promotes CMAKE_THREAD_PREFER_PTHREAD to get -pthread It's THREADS_PREFER_PTHREAD_FLAG for that. CMake's FindBoost and FindThreads could use some work to use `-pthread` more completely (perhaps with a policy to use it by default on appropriate compilers), and there is an issue related to this here: https://gitlab.kitware.com/cmake/cmake/issues/18638 However, that does not mean the above change should be reverted. -Brad
Bug#813875: insighttoolkit4: FTBFS on i386 (member reference base type 'void' is not a structure or union)
On 02/06/2016 06:34 AM, Gert Wollny wrote: > As you can see, this is actually a bug in castxml [snip] > would you please consider filing a bug upstream I've recorded the issue upstream here: https://github.com/CastXML/CastXML/issues/47 Please follow that for updates. -Brad
Bug#667417: fixing __float128?
On 07/27/2012 02:17 AM, Mathieu Malaterre wrote: On Fri, Jul 27, 2012 at 4:13 AM, Steve M. Robbins st...@sumost.ca wrote: Hey ... is there a trick to fix #654718 similar to that for __int128? #undef _GLIBCXX_USE_FLOAT128 No, that is not the same problem. The __int128 fix told the *standard library* headers not to use the type by setting its own preprocessor symbols correctly. In this case the problem is in the fftw headers. The fftw3.h header contains a big #if test to decide whether the __float128 type is available. It *already* contains an exclusion for the Intel compiler. It also needs an exclusion for gccxml just as it would for any other compiler that defines __GNUC__ but is not really the GNU compiler version it reports. This is what I suggested in the original thread on our list: http://thread.gmane.org/gmane.comp.compilers.gccxml/602 Other projects have accepted upstream modifications for the same reason, such as Boost: http://svn.boost.org/svn/boost/tags/release/Boost_1_50_0/boost/config/compiler/gcc_xml.hpp -Brad -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675181: gccxml cannot parse limits under GCC 4.7.1
On 07/26/2012 05:31 AM, Mathieu Malaterre wrote: reopen 675181 severity grave retitle 675181 gccxml cannot parse limits under GCC 4.7.1 forwarded 675181 http://www.gccxml.org/Bug/view.php?id=13372 thanks Not sure if this is ideal to reopen the bug instead of creating a new one. But I believe doko intention was to kill #667417 with this gccxml bug. So continuing the effort. I can reproduce the __int128 issue with current gccxml package in debian. It seems it also affect upstream (not checked if this is fixed), since upstream bug tracker reports it as open on 2012/07/02. Brad could you please confirm bug 13372 in gccxml stills affect current gccxml ? It did until I just fixed it. Thanks for reminding me. -Brad -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On 07/11/2012 03:40 AM, Evgeni Golov wrote: Dear cmake maintainers, could you please have a look at the bug (and build log) and guess why 2.8.9 stopped building the libraries in the mdrun target? Is it a bad cmake file or a regression in cmake? It is a regression in CMake AFAICT. I bisected it down to here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732 Try adding the flag -DCMAKE_INSTALL_DEFAULT_COMPONENT_NAME=Unspecified to the CMake configuration step to work around the problem. We'll try to get this fixed before the final 2.8.9 release. -Brad -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On 07/11/2012 02:29 PM, Brad King wrote:
Try adding the flag
-DCMAKE_INSTALL_DEFAULT_COMPONENT_NAME=Unspecified
to the CMake configuration step to work around the problem.
Nevermind about this workaround. I had tested it with a leftover
build of a good version during git bisect.
This hunk:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732#patch4
@@ -35,7 +36,9 @@ cmInstallCommandArguments::cmInstallCommandArguments()
,NamelinkOnly (Parser, NAMELINK_ONLY , ArgumentGroup)
,NamelinkSkip (Parser, NAMELINK_SKIP , ArgumentGroup)
,GenericArguments(0)
-{}
+{
+ this-Component.SetDefaultString(defaultComponent.c_str());
+}
Seems to have reversed a previous fix:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43cad3e4
of a problem similar to what we observe here. The SetDefaultString
code never worked AFAICT.
-Brad
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On 07/11/2012 02:55 PM, Brad King wrote: This hunk: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732#patch4 Seems to have reversed a previous fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43cad3e4 of a problem similar to what we observe here. This should fix it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8720aa04 Ideally we should add a test for this case but I have no time now. We'll include the fix in the next 2.8.9 rc. -Brad -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
