Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/05/14 14:40, Guy Harris wrote: On Jan 5, 2014, at 10:00 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 01/04/2014 09:51 PM, Guy Harris wrote: On Jan 4, 2014, at 9:17 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: 6) make # just to show that it works (I stopped the build after a few C files were compiled) 7) vi ../CMakeLists.txt 8) Put -Wshorten-64-to-32 back where it was (at the end of WIRESHARK_C_ONLY_FLAGS) 9) cmake .. Presumably CMake then reports something such as -- Checking for flag: -Wshorten-64-to-32 -- Performing Test WS_C_FLAG_VALID44 -- Performing Test WS_C_FLAG_VALID44 - Success in that case, meaning it thinks -Wshorten-64-to-32 *is* supported by the C compiler? Well it doesn't do the full check on this (cached) pass, it just says: -- Checking for flag: -Wjump-misses-init -- Checking for flag: -Wshorten-64-to-32 -- C-Flags: -Wall -W -Wextra -Wendif-labels [...] So is the issue that the tests have the ordinal number of the flag, rather than the name of the flag, in the name of the test, with that name being used when caching results, so that the cache is bogus if you've reordered the flags since the cached results are generated? Either that or it was caching the variable name. (Presumably this also caused some flag that *does* work *not* to be added, as the results of the test of -Wshorten-64-to-32 were used on that flag.) That is my presumption as well. Regardless, it appears Joerg has fixed it in r54638. :-) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/04/2014 09:51 PM, Guy Harris wrote: On Jan 4, 2014, at 9:17 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: Ah, OK, I found a way to reproduce it (in current SVN): 1) rm -rf _cmake_build 2) mkdir _cmake_build cd _cmake_build 3) vi ../CMakeLists.txt 4) Move the -Wshorten-64-to-32 flag from where it is in the file to just after -Wshadow 5) cmake .. Presumably CMake then reports something such as -- Checking for flag: -Wshorten-64-to-32 -- Performing Test WS_C_FLAG_VALID44 -- Performing Test WS_C_FLAG_VALID44 - Failed in that case, meaning it thinks -Wshorten-64-to-32 isn't supported by the C compiler? Yep: -- Checking for flag: -Wshorten-64-to-32 -- Performing Test WS_C_FLAG_VALID39 -- Performing Test WS_C_FLAG_VALID39 - Failed 6) make # just to show that it works (I stopped the build after a few C files were compiled) 7) vi ../CMakeLists.txt 8) Put -Wshorten-64-to-32 back where it was (at the end of WIRESHARK_C_ONLY_FLAGS) 9) cmake .. Presumably CMake then reports something such as -- Checking for flag: -Wshorten-64-to-32 -- Performing Test WS_C_FLAG_VALID44 -- Performing Test WS_C_FLAG_VALID44 - Success in that case, meaning it thinks -Wshorten-64-to-32 *is* supported by the C compiler? Well it doesn't do the full check on this (cached) pass, it just says: -- Checking for flag: -Wjump-misses-init -- Checking for flag: -Wshorten-64-to-32 -- C-Flags: -Wall -W -Wextra -Wendif-labels [...] Which version of which compiler is this? (You said Fedora, so I presume it's either GCC or Clang; which version of Fedora is it?) I first hit the problem on Fedora 18 (I'd have to check on the compiler version but it was gcc). The method quoted above was reproduced on Fedora 19 (gcc 4.8.2). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Jan 5, 2014, at 10:00 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 01/04/2014 09:51 PM, Guy Harris wrote: On Jan 4, 2014, at 9:17 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: 6) make # just to show that it works (I stopped the build after a few C files were compiled) 7) vi ../CMakeLists.txt 8) Put -Wshorten-64-to-32 back where it was (at the end of WIRESHARK_C_ONLY_FLAGS) 9) cmake .. Presumably CMake then reports something such as -- Checking for flag: -Wshorten-64-to-32 -- Performing Test WS_C_FLAG_VALID44 -- Performing Test WS_C_FLAG_VALID44 - Success in that case, meaning it thinks -Wshorten-64-to-32 *is* supported by the C compiler? Well it doesn't do the full check on this (cached) pass, it just says: -- Checking for flag: -Wjump-misses-init -- Checking for flag: -Wshorten-64-to-32 -- C-Flags: -Wall -W -Wextra -Wendif-labels [...] So is the issue that the tests have the ordinal number of the flag, rather than the name of the flag, in the name of the test, with that name being used when caching results, so that the cache is bogus if you've reordered the flags since the cached results are generated? (Presumably this also caused some flag that *does* work *not* to be added, as the results of the test of -Wshorten-64-to-32 were used on that flag.) Which version of which compiler is this? (You said Fedora, so I presume it's either GCC or Clang; which version of Fedora is it?) I first hit the problem on Fedora 18 (I'd have to check on the compiler version but it was gcc). The method quoted above was reproduced on Fedora 19 (gcc 4.8.2). Apparently GNU GCC 4.8.2 doesn't support -Wshorten-64-to-32. So maybe Apple were the first people to realize that maybe checking for inadvertently chopping off the upper 32 bits of a value, because your code wasn't 64-bit-clean, was a good idea? Perhaps someday somebody involved with GCC will realize that maybe checking for *all* shortenings without an explicit cast might be a good idea (which Microsoft figured out a while ago, that being one of the reasons why the build breaks on the Windows builds - MSVC is treating such a shortening as an error). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/03/2014 01:31 PM, Jeff Morriss wrote: On 01/02/2014 07:42 PM, Joerg Mayer wrote: On Thu, Jan 02, 2014 at 04:30:14PM -0800, Guy Harris wrote: Are we really encountering a case where the C compiler accepts -Wshorten-64-to-32 but the C++ compiler doesn't, or *vice versa*? Or are we encountering a case where *neither* compiler accepts it, but CMake isn't detecting that? Neither compiler supports that option. It's highly unlikely that this directory was previously used with a compiler that *did* support it (unless Fedora pushed out a compiler downgrade) but I suppose it is possible. I don't know. On my (32-bit) system, both compilers correctly report that it is not supported. I'd need to see the cmake output on a system that has this problem. Unfortunately the evidence is all gone now. Maybe if I hit the problem again in the future... Ah, OK, I found a way to reproduce it (in current SVN): 1) rm -rf _cmake_build 2) mkdir _cmake_build cd _cmake_build 3) vi ../CMakeLists.txt 4) Move the -Wshorten-64-to-32 flag from where it is in the file to just after -Wshadow 5) cmake .. 6) make # just to show that it works (I stopped the build after a few C files were compiled) 7) vi ../CMakeLists.txt 8) Put -Wshorten-64-to-32 back where it was (at the end of WIRESHARK_C_ONLY_FLAGS) 9) cmake .. 10) make # now it doesn't work, complaining that -Wshorten-64-to-32 is an unknown option -- It seems cmake isn't caching the result of the test but rather the value of the variable we're storing the result in (e.g., WS_C_FLAG_VALID39). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Sat, Jan 04, 2014 at 12:17:35PM -0500, Jeff Morriss wrote: It's highly unlikely that this directory was previously used with a compiler that *did* support it (unless Fedora pushed out a compiler downgrade) but I suppose it is possible. I don't know. On my (32-bit) system, both compilers correctly report that it is not supported. I'd need to see the cmake output on a system that has this problem. Unfortunately the evidence is all gone now. Maybe if I hit the problem again in the future... Ah, OK, I found a way to reproduce it (in current SVN): 1) rm -rf _cmake_build 2) mkdir _cmake_build cd _cmake_build 3) vi ../CMakeLists.txt 4) Move the -Wshorten-64-to-32 flag from where it is in the file to just after -Wshadow 5) cmake .. 6) make # just to show that it works (I stopped the build after a few C files were compiled) 7) vi ../CMakeLists.txt 8) Put -Wshorten-64-to-32 back where it was (at the end of WIRESHARK_C_ONLY_FLAGS) 9) cmake .. 10) make # now it doesn't work, complaining that -Wshorten-64-to-32 is an unknown option -- It seems cmake isn't caching the result of the test but rather the value of the variable we're storing the result in (e.g., WS_C_FLAG_VALID39). OK, I still tend to regard this as a caching problem. It also looks like an unusual use case what you are doing. What prompted you to do that? Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/04/2014 06:01 PM, Joerg Mayer wrote: On Sat, Jan 04, 2014 at 12:17:35PM -0500, Jeff Morriss wrote: It's highly unlikely that this directory was previously used with a compiler that *did* support it (unless Fedora pushed out a compiler downgrade) but I suppose it is possible. I don't know. On my (32-bit) system, both compilers correctly report that it is not supported. I'd need to see the cmake output on a system that has this problem. Unfortunately the evidence is all gone now. Maybe if I hit the problem again in the future... Ah, OK, I found a way to reproduce it (in current SVN): 1) rm -rf _cmake_build 2) mkdir _cmake_build cd _cmake_build 3) vi ../CMakeLists.txt 4) Move the -Wshorten-64-to-32 flag from where it is in the file to just after -Wshadow 5) cmake .. 6) make # just to show that it works (I stopped the build after a few C files were compiled) 7) vi ../CMakeLists.txt 8) Put -Wshorten-64-to-32 back where it was (at the end of WIRESHARK_C_ONLY_FLAGS) 9) cmake .. 10) make # now it doesn't work, complaining that -Wshorten-64-to-32 is an unknown option -- It seems cmake isn't caching the result of the test but rather the value of the variable we're storing the result in (e.g., WS_C_FLAG_VALID39). OK, I still tend to regard this as a caching problem. It also looks like an unusual use case what you are doing. What prompted you to do that? Just looking for a way to reproduce the problem. The idea it was caching the wrong thing popped into my head. I think it explains well why I hit it and why Alexis said he occasionally hits it: when we hit it it's probably because someone reordered the flags. Could the variable to store the names simply include the compiler option? It doesn't appear that the code relies on them being numbered 1,2,3,4... Well, that doesn't work because it doesn't seem to like the variable name very much:: -- Checking for flag: -Wc++-compat RegularExpression::compile(): Nested *?+. RegularExpression::compile(): Error in compile. CMake Error at /usr/share/cmake/Modules/CheckCSourceCompiles.cmake:30 (if): if given arguments: WS_C_FLAG_VALID-Wc++-compat MATCHES ^WS_C_FLAG_VALID-Wc++-compat\$ Regular expression ^WS_C_FLAG_VALID-Wc++-compat$ cannot compile Hmmm ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Jan 4, 2014, at 9:17 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: Ah, OK, I found a way to reproduce it (in current SVN): 1) rm -rf _cmake_build 2) mkdir _cmake_build cd _cmake_build 3) vi ../CMakeLists.txt 4) Move the -Wshorten-64-to-32 flag from where it is in the file to just after -Wshadow 5) cmake .. Presumably CMake then reports something such as -- Checking for flag: -Wshorten-64-to-32 -- Performing Test WS_C_FLAG_VALID44 -- Performing Test WS_C_FLAG_VALID44 - Failed in that case, meaning it thinks -Wshorten-64-to-32 isn't supported by the C compiler? 6) make # just to show that it works (I stopped the build after a few C files were compiled) 7) vi ../CMakeLists.txt 8) Put -Wshorten-64-to-32 back where it was (at the end of WIRESHARK_C_ONLY_FLAGS) 9) cmake .. Presumably CMake then reports something such as -- Checking for flag: -Wshorten-64-to-32 -- Performing Test WS_C_FLAG_VALID44 -- Performing Test WS_C_FLAG_VALID44 - Success in that case, meaning it thinks -Wshorten-64-to-32 *is* supported by the C compiler? Which version of which compiler is this? (You said Fedora, so I presume it's either GCC or Clang; which version of Fedora is it?) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/02/2014 07:42 PM, Joerg Mayer wrote: On Thu, Jan 02, 2014 at 04:30:14PM -0800, Guy Harris wrote: Are we really encountering a case where the C compiler accepts -Wshorten-64-to-32 but the C++ compiler doesn't, or *vice versa*? Or are we encountering a case where *neither* compiler accepts it, but CMake isn't detecting that? Neither compiler supports that option. It's highly unlikely that this directory was previously used with a compiler that *did* support it (unless Fedora pushed out a compiler downgrade) but I suppose it is possible. I don't know. On my (32-bit) system, both compilers correctly report that it is not supported. I'd need to see the cmake output on a system that has this problem. Unfortunately the evidence is all gone now. Maybe if I hit the problem again in the future... ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
Hi Jeff, I have also some time the some error message... With autotools, -Wshorten-64-to-32 is limited to only C... Regards, On Thu, Jan 2, 2014 at 10:02 PM, Jeff Morriss jeff.morriss...@gmail.comwrote: Hi folks, It took me a while to get my cmake build going again today; one of the reasons was that the builds would immediately fail with: cc: error: unrecognized command line option -Wshorten-64-to-32 As far as I can tell the problem is simply that check_c_compiler_flag() isn't working in my version of cmake (2.8.11): it always returns 1. Or does it not work for others? Regards, -Jeff ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Jan 2, 2014, at 1:34 PM, Alexis La Goutte alexis.lagou...@gmail.com wrote: I have also some time the some error message... With autotools, -Wshorten-64-to-32 is limited to only C... Because, to quote the comment in configure.ac: # The Qt headers generate a ton of shortening errors on 64-bit systems # so only enable this for C for now. I.e., it's not that g++ or clang++ don't support the option, it's that the bulk of our C++ code uses a framework that doesn't cast away those warnings (or fix them). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/02/14 16:34, Alexis La Goutte wrote: Hi Jeff, I have also some time the some error message... Only sometimes? I had to take that option out of CMakeLists.txt to get it compile. With autotools, -Wshorten-64-to-32 is limited to only C... True but my problem is with C compiler (it doesn't get past compiling the first file). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Jan 2, 2014, at 1:55 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 01/02/14 16:34, Alexis La Goutte wrote: Hi Jeff, I have also some time the some error message... Only sometimes? I had to take that option out of CMakeLists.txt to get it compile. With autotools, -Wshorten-64-to-32 is limited to only C... True but my problem is with C compiler (it doesn't get past compiling the first file). I infer from the cc in cc: error: unrecognized command line option -Wshorten-64-to-32 that this is UN*X (or Windows with MinGW or Cygwin or something such as that). If it's UN*X, presumably you can try autotools; with autotools, does the compiler detect that the compiler doesn't support -Wshorten-64-to-32? If not, the test needs more work in autotools, and those changes might also apply to CMake; if so, this is an issue with the CMake tests for does this flag work? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
Hi, On Thursday 02 January 2014 16:02:08 Jeff Morriss wrote: It took me a while to get my cmake build going again today; one of the reasons was that the builds would immediately fail with: cc: error: unrecognized command line option -Wshorten-64-to-32 As far as I can tell the problem is simply that check_c_compiler_flag() isn't working in my version of cmake (2.8.11): it always returns 1. Or does it not work for others? I sometimes have this issue too, but it got fixed by clearing the build directory (`rm -rf build`) and then configuring the tree again with cmake. In CMakeFiles/CMakeError.log, I can find that warning too, it seems that it gets dropped by cmake (perhaps because it is not recognized?). This is CMake 2.8.12.1 and GCC 4.8.2. Regards, Peter ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/02/14 17:05, Peter Wu wrote: Hi, On Thursday 02 January 2014 16:02:08 Jeff Morriss wrote: It took me a while to get my cmake build going again today; one of the reasons was that the builds would immediately fail with: cc: error: unrecognized command line option -Wshorten-64-to-32 As far as I can tell the problem is simply that check_c_compiler_flag() isn't working in my version of cmake (2.8.11): it always returns 1. Or does it not work for others? I sometimes have this issue too, but it got fixed by clearing the build directory (`rm -rf build`) and then configuring the tree again with cmake. Oh, weird. I blew away my build directory several times today (for other reasons) and it never solved this problem. But I tried just now and it did... Weird! ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On 01/02/14 17:15, Guy Harris wrote: On Jan 2, 2014, at 1:55 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 01/02/14 16:34, Alexis La Goutte wrote: Hi Jeff, I have also some time the some error message... Only sometimes? I had to take that option out of CMakeLists.txt to get it compile. With autotools, -Wshorten-64-to-32 is limited to only C... True but my problem is with C compiler (it doesn't get past compiling the first file). I infer from the cc in cc: error: unrecognized command line option -Wshorten-64-to-32 that this is UN*X (or Windows with MinGW or Cygwin or something such as that). If it's UN*X, presumably you can try autotools; with autotools, does the compiler detect that the compiler doesn't support -Wshorten-64-to-32? Oh, sorry, yes, it works with autotools. That's what I normally use and, well, I would have fixed it or complained long ago if it didn't work ;-). checking whether we can add -Wshorten-64-to-32 to CFLAGS... no If not, the test needs more work in autotools, and those changes might also apply to CMake; if so, this is an issue with the CMake tests for does this flag work? Cmake has that function which I listed that is supposed to do it for us but it doesn't seem to work (at least for me or at least not all the time). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Jan 2, 2014, at 2:44 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: Cmake has that function which I listed that is supposed to do it for us but it doesn't seem to work (at least for me or at least not all the time). Given that at least two people have said that blowing away the build directory sometimes fixes the problem, perhaps something's being cached? But, if that's the case, was it cached when a compiler that *does* support -Wshorten-64-to-32 was used, and then a *different* compiler was used? (Building in a directory stored on a file server can make this more likely to happen, as you might be building on machine A and then re-building on machine B without clearing out all the stuff left around by the configure-and-build on machine A.) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Thu, Jan 02, 2014 at 03:16:17PM -0800, Guy Harris wrote: On Jan 2, 2014, at 2:44 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: Cmake has that function which I listed that is supposed to do it for us but it doesn't seem to work (at least for me or at least not all the time). Given that at least two people have said that blowing away the build directory sometimes fixes the problem, perhaps something's being cached? Yes, that's the case. Just create an empty build dir, run cmake, then run cmake again. The second run will be much faster and the output much shorter. Basically everything that is about (positive) detection of build environment stuff is (permanently) cached. You will either need to unset that variable (e.g. with ccmake) or remove the CMakeCache.txt file. But, if that's the case, was it cached when a compiler that *does* support -Wshorten-64-to-32 was used, and then a *different* compiler was used? (Building in a directory stored on a file server can make this more likely to happen, as you might be building on machine A and then re-building on machine B without clearing out all the stuff left around by the configure-and-build on machine A.) I will change the cmake tests to run separately for c and c++ - if I read the commits correctly you did this for autotools already. I (and thus the code) currently assume that the c and c++ compiler are from the same source. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Jan 2, 2014, at 4:21 PM, Joerg Mayer jma...@loplof.de wrote: On Thu, Jan 02, 2014 at 03:16:17PM -0800, Guy Harris wrote: But, if that's the case, was it cached when a compiler that *does* support -Wshorten-64-to-32 was used, and then a *different* compiler was used? (Building in a directory stored on a file server can make this more likely to happen, as you might be building on machine A and then re-building on machine B without clearing out all the stuff left around by the configure-and-build on machine A.) I will change the cmake tests to run separately for c and c++ - if I read the commits correctly you did this for autotools already. I (and thus the code) currently assume that the c and c++ compiler are from the same source. Even if they're from the same source, they might not accept the same flags. In *most* cases, that's an indication that you have a mismatched C-compiler/C++-compiler pair, and the autoconf script reports it as such with a warning, but, in two cases, it's expected - one compiler might accept -Wmissing-prototypes or -Wmissing-declarations when the other doesn't. Are we really encountering a case where the C compiler accepts -Wshorten-64-to-32 but the C++ compiler doesn't, or *vice versa*? Or are we encountering a case where *neither* compiler accepts it, but CMake isn't detecting that? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] cmake giving options the compiler does not understand
On Thu, Jan 02, 2014 at 04:30:14PM -0800, Guy Harris wrote: Are we really encountering a case where the C compiler accepts -Wshorten-64-to-32 but the C++ compiler doesn't, or *vice versa*? Or are we encountering a case where *neither* compiler accepts it, but CMake isn't detecting that? I don't know. On my (32-bit) system, both compilers correctly report that it is not supported. I'd need to see the cmake output on a system that has this problem. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
