On Mon, Jul 29, 2024 at 1:57 AM Lucas Nussbaum wrote:
> Source: cmake
> Version: 3.30.1-1
...
> 492/721 Test #501: RunCMake.file-DOWNLOAD
> ..***Failed
...
> stdout does not match that expected.
This is due to a change in curl's output introduced in curl 8.9.
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:
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 dist
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-t
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 dur
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
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
On 07/27/2012 02:17 AM, Mathieu Malaterre wrote:
> On Fri, Jul 27, 2012 at 4:13 AM, Steve M. Robbins 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* he
On 07/26/2012 05:31 AM, Mathieu Malaterre wrote:
> reopen 675181
> severity grave
> retitle 675181 gccxml cannot parse 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 bel
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.
Thi
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"
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 bise
12 matches
Mail list logo
