[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wireshark-dev
Subject:    Re: [Wireshark-dev] Mac Build Error
From:       David Morsberger <dave () morsberger ! com>
Date:       2016-01-26 15:02:33
Message-ID: 84C2ADEB-3571-4F82-8639-37CC77EBF285 () morsberger ! com
[Download RAW message or body]


> On Jan 26, 2016, at 3:33 AM, Guy Harris <guy@alum.mit.edu> wrote:
> 
> On Jan 25, 2016, at 4:39 PM, David Morsberger <dave@morsberger.com> wrote:
> 
> > After a detailed analysis of cmake, I believe this is the solution and not just \
> > fixing the symptom.  
> > cmake uses /usr/bin/xcodebuild when using -G Xcode. The internal behavior of \
> > cmake is significantly different when using xcodebuild in contrast to generating \
> > Unix makefiles. Specifically, try_run used by CHECK_C_SOURCE_RUNS and try_compile \
> > used by CHECK_C_SOURCE_COMPILES do not use the environment variables in the same \
> > way when using the Xcode Generator.
> 
> To which environment variables are you referring?  When I was looking at this, I \
> wasn't setting *any* environment variables; are you saying that CMake passes some \
> flags to the build tools by setting environment variables rather than by passing \
> them on the command line? (CMAKE_REQUIRED_FLAGS is a CMake variable, not an \
> environment variable; that, or something constructed from that such as the \
> COMPILE_DEFINITIONS parameter, appears to be what's being handled differently by \
> different generators. It *is* handled correctly by try_compile, and by the compile \
> stage of try_run - i.e., the flags are passed to the compiler driver in that stage \
> - but not by the link stage of try_run for Xcode, although it is passed to the \
> compiler driver by the link stage of try_run for Unix makefiles.)

I was referring to CMAKE_ variables. 

> 
> > Guy, the normal behavior of CHECK_C_SOURCE_RUNS for Unix makefiles will check \
> > linker flags because it does attempt to link and run the resulting executable.
> 
> The normal behavior of CHECK_C_SOURCE_RUNS for *all* generators attempts to link \
> and run the resulting executable (except when cross-compiling, obviously); that's \
> not a difference between Unix makefiles and Xcode.  That's why the name ends with \
> "_RUNS". 
> The problem is that the flags specified by CMAKE_REQUIRED_FLAGS aren't being passed \
> to the compiler driver in the link stage with the Xcode generator, so they're not \
> *getting* tested by the link-and-run stage.

Xcode is a beast of its own and I'm sure one can create a career understanding it and \
finding out how to make it work like a traditional makefile. I wouldn't begin to know \
how to pass the linker flag to ‘xcodebuild -project Wireshark.xcodeproj -target \
wireshark-gtk -configuration Debug' (at least I think that is the command).

Sometimes I punt and say I just have to deal with the uncertainties of the system \
under test. I usually never punt until I have tried to figure it out.

> 
> > This is why ‘—-as-needed' fails when using basic make.
> 
> The underlying problem is
> 
> 	https://public.kitware.com/Bug/view.php?id=15934
> 
> I have not yet looked deeply enough into the CMake source to see why setting \
> CMAKE_REQUIRED_FLAGS affects the link stage with the Unix makefile generator but \
> not with the Xcode generator.  I've given up on waiting for anybody from Kitware or \
> anybody else to answer the email I sent to the list, so I filed the bug in question \
> and will wait for somebody to answer the bug (hopefully with something more useful \
> than "you're holding it wrong"). 
> For now, I've removed all the code that attempts to find out whether a given linker \
> flag works

I saw your change. This is an affirmative change meaning ‘we know it works with \
these two systems' as opposed to being uncertain meaning ‘we know it doesn't work \
with these two systems, XCODE and MSVC, and we will try to the other systems' \
___________________________________________________________________________ Sent via: \
                Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe


[prev in list] [next in list] [prev in thread] [next in thread]