CPPFLAGS and LDFLAGS in wxPython

[Mojca Miklavec]

Hello,

I'm packaging wxWidgets and wxPython for a package manager on macOS.

TL;DR: how do I properly set CPPFLAGS/CXXFLAGS and LDFLAGS when
installing wxPython?


Long version below:

Recently we got an interesting bug report:
https://trac.macports.org/ticket/53040

Let me explain the background.
OS X < 10.9 doesn't support C++11 by default, but when installing the
package manager, users are able to choose libc++ as their default
stdlib which supports C++11. Due to an increasing amount of software
nowadays requiring C++11, more users are expected to do that

wxWidgets builds without any issues. I only have to set
CPPFLAGS="-stdlib=libc++"
and additionally
LDFLAGS="-stdlib=libc++"

(Usually software would only require the first one to be set,
wxWidgets requires both, but that's fine.)

The problem appears when building wxPython. I build wxPython with
setup.py WX_CONFIG=/path/to/wx-config
so that only the Python support is built on top of the exiting wxWidgets.

I additionally replace WXPORT in config.py from 'osx_carbon' to
'osx_cocoa' (not that it should matter in any way).

Now, wx-config would tell me exactly which compiler it was built with:
$ wx-config --cc
/usr/bin/clang
$ wx-config --cxx
/usr/bin/clang++
but I don't find any way to "recover" the "-stdlib=libc++" flag. None of
$ wx-config --libs
$ wx-config --cflags
$ wx-config --cxxlags
$ wx-config --cpplags
would tell me the stdlib.


I can fix the situation in any of the following ways:

(a) patch wxWidgets in such a way that
wx-config --[one-of-those-flags]
would also return me -stdlib=libc++

(b) patch setup.py in wxPython with:
cflags.append('-stdlib=libc++')
lflags.append('-stdlib=libc++')

(c) provide those flags in environment or as arguments of setup.py

I would prefer (a), but would like to avoid (b) if possible.
But I would prefer to get the official answer (and perhaps ask for an
official patch).

Thank you,
Mojca

[Vadim Zeitlin]

On Mon, 12 Dec 2016 16:49:56 +0100 Mojca Miklavec wrote:

MM> Let me explain the background.
MM> OS X < 10.9 doesn't support C++11 by default, but when installing the
MM> package manager, users are able to choose libc++ as their default
MM> stdlib which supports C++11. Due to an increasing amount of software
MM> nowadays requiring C++11, more users are expected to do that
MM>
MM> wxWidgets builds without any issues. I only have to set
MM> CPPFLAGS="-stdlib=libc++"
MM> and additionally
MM> LDFLAGS="-stdlib=libc++"
MM>
MM> (Usually software would only require the first one to be set,
MM> wxWidgets requires both, but that's fine.)

I don't see how setting just CPPFLAGS can work for the other software but,
in any case, I have a suggestion that should both answer your question and
only use one variable and not two: use CXX="c++ -stdlib=libc++" instead. As
$CXX (and not ld) is used for linking as well as compiling, this should be
enough and you should be able to recover the compiler used with `wx-config
--cxx` option.

And this even makes more sense, IMHO: using different standard libraries
is similar to using 2 different compilers because this means using 2
incompatible ABIs.

Regards,
VZ

[Hans Mackowiak]

Hello,
in my binding rwx for ruby i did a some checking that might be useful
for you:
https://github.com/Hanmac/rwx/blob/master/ext/extconf.rb#L87-L100

i don't know what you can use for checking, but that what i did.

first:
have macro "HAVE_TYPE_TRAITS","wx/setup.h"
if that macro is in the setup.h then wxWidgets is build with "-
std=c++11"

second checks for clang (tested on Linux and OSX)
!have_macro("HAVE_ABI_FORCEDUNWIND","wx/setup.h")
clang with libc++ doesn't have forceunwind

second extra check:
if using "-stdlib=libc++" causes
have_macro "_LIBCPP_VERSION","ciso646"
to be true, then wxWidgets was build with "-stdlib=libc++" it.
(ciso646 is some kind of special header)

Regards,

Hanmac