Home page logo

wireshark logo Wireshark mailing list archives

Re: cmake giving options the compiler does not understand
From: Guy Harris <guy () alum mit edu>
Date: Sun, 5 Jan 2014 11:40:45 -0800

On Jan 5, 2014, at 10:00 AM, Jeff Morriss <jeff.morriss.ws () 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.ws () 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-request () wireshark org?subject=unsubscribe

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]