| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0015736 | CMake | Modules | public | 2015-09-10 13:46 | 2016-02-01 09:10 | ||||
| Reporter | Felix Geyer | ||||||||
| Assigned To | Brad King | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | CMake 3.4 | Fixed in Version | CMake 3.4 | ||||||
| Summary | 0015736: FeatureTesting unreliable | ||||||||
| Description | The CompileFeatures test fails in Debian on the architecture alpha. My guess is that it's a general problem and other architectures just got lucky. The problem seems to be that Modules/Internal/FeatureTesting.cmake doesn't add a terminator (\0 or \n for example) at the start of const char features. As a result a printable character can appear in the binary right before "${lang}_FEATURE:". So when cmake extracts strings from the binary it reads "kC_FEATURE:1c_function_prototypes\n". The extra "k" at the start confuses the module as it expects "C_FEATURE". This code in Modules/Internal/FeatureTesting.cmake might be supposed to add a null character at the start: const char features[] = {\"\"\n") However if I'm not mistaken C just concats string literals that are space separated -> it's a noop. Replacing that empty string literal with "\0" fixes the problem. Original bug report with an analysis of the problem: https://bugs.debian.org/789807 [^] | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0039400) Brad King (manager) 2015-09-10 14:16 |
Modules/CMakeDetermineCompilerId.cmake uses a similar approach but can tolerate content before and after the intended string because it does if("${info}" MATCHES "INFO:compiler\\[([^]\"]*)\\]") on the "info" value extracted from the binary, which is intended to be of the form INFO:compiler[value] for the value to be "value". If this is extracted with extra content such as xxINFO:compiler[value]xx it will still match the value. |
|
(0039401) Brad King (manager) 2015-09-10 14:44 |
Since the <LANG>_FEATURES:... strings are all together in a single string literal in the binary we know there is nothing before or after them except for the first and last entry. We already have a trailing newline after the last entry. We can just use a leading newline before the first entry as suggested in the description. This should fix it: Features: Extract strings from test binary more reliably http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=150e1b27 [^] |
|
(0040397) Robert Maynard (manager) 2016-02-01 09:10 |
Closing resolved issues that have not been updated in more than 4 months. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2015-09-10 13:46 | Felix Geyer | New Issue | |
| 2015-09-10 14:02 | Brad King | Target Version | => CMake 3.4 |
| 2015-09-10 14:16 | Brad King | Note Added: 0039400 | |
| 2015-09-10 14:44 | Brad King | Note Added: 0039401 | |
| 2015-09-10 14:44 | Brad King | Assigned To | => Brad King |
| 2015-09-10 14:44 | Brad King | Status | new => resolved |
| 2015-09-10 14:44 | Brad King | Resolution | open => fixed |
| 2015-09-10 14:44 | Brad King | Fixed in Version | => CMake 3.4 |
| 2016-02-01 09:10 | Robert Maynard | Note Added: 0040397 | |
| 2016-02-01 09:10 | Robert Maynard | Status | resolved => closed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |