Opened 2 years ago

Last modified 2 years ago

#57615 assigned defect

p5-wx uses libc++ when it shouldn't, resulting in fatal error: 'tr1/type_traits' file not found

Reported by: ryandesign (Ryan Schmidt) Owned by: mojca (Mojca Miklavec)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: p5-wx

Description

p5-wx fails to build on OS X 10.8 (and earlier I'm sure):

/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/strvararg.h:30:18: fatal error: 'tr1/type_traits' file not found
        #include <tr1/type_traits>
                 ^

This is because it's trying to use libc++:

/usr/bin/clang++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -stdlib=libc++ -UWX_PRECOMP   -c  -I. -I. -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/include/osx_cocoa-unicode-3.0 -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0  -fno-common -DPERL_DARWIN -mmacosx-version-min=10.8 -pipe -Os -fno-strict-aliasing -fstack-protector -I/opt/local/include -DPERL_USE_SAFE_PUTENV -arch x86_64 -O3   -DVERSION=\"0.9932\" -DXS_VERSION=\"0.9932\"  "-I/opt/local/lib/perl5/5.26/darwin-thread-multi-2level/CORE"  -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__   Event.c

It shouldn't be doing that; it should use ${configure.cxx_stdlib}.

Change History (3)

comment:1 Changed 2 years ago by mojca (Mojca Miklavec)

I need to check. Is this flag hardcoded in p5-wx sources? Are you using the default installation or the one with libc++ default?

I just need to add that while I agree with you, the port absolutely needs to be compiled with the same cxx_stdlib as wxWidgets and this often gets pretty tricky, there are still issues with some Python ports and upstream told me to specify the compiler with CXX=/path/to/clang -stdlib=libc++ if I want the python modules to be compiled correctly on libc++ setups on older machines. (The port should not hardcode the stdlib flag in any case though.)

comment:2 in reply to:  1 Changed 2 years ago by ryandesign (Ryan Schmidt)

Replying to mojca:

I need to check. Is this flag hardcoded in p5-wx sources?

Yes.

Are you using the default installation or the one with libc++ default?

Whatever is default. The failure happened on the buildbot.

I just need to add that while I agree with you, the port absolutely needs to be compiled with the same cxx_stdlib as wxWidgets and this often gets pretty tricky, there are still issues with some Python ports and upstream told me to specify the compiler with CXX=/path/to/clang -stdlib=libc++ if I want the python modules to be compiled correctly on libc++ setups on older machines. (The port should not hardcode the stdlib flag in any case though.)

I don't know which one needs to be used here. I just know that the output above seems to show that wxWidgets understands that it is running on a libstdc++ system, based on the use of tr1, and the error occurs because p5-wx is circumventing that and forcing libc++, which does not understand tr1.

I've learned that python modules don't support C++. They compile C++ code using the C compiler, which is wrong and is why our cxx11 1.1 portgroup's work has no effect on most python modules. (There is a 13-year-old distutils bug about that.) Given that, it's surprising how many python modules use C++. I'm not sure if there's a good way to fix this in the python portgroup, since it's up to each port to know whether it is using the C compiler to compile C code (which should not get the -stdlib flag) or C++ code (which should). The situation basically sucks. Upstream python should resolve their distutils bug and we should backport it to all versions of python.

comment:3 Changed 2 years ago by mojca (Mojca Miklavec)

OK, the file build/Wx/build/MakeMaker/MacOSX_GCC.pm contains a lot of strange stuff:

if ($ENV{MACOSX_DEPLOYMENT_TARGET}) {
  my ($dt0, $dt1, @discard) = split(/[^0-9]+/,$ENV{MACOSX_DEPLOYMENT_TARGET} );
  if (($dt0 <= 10) && ( $dt1 < 3 )) {
	die "Please set MACOSX_DEPLOYMENT_TARGET to 10.3 or above";
  }
}

my $tools43 = '/Applications/Xcode.app/Contents/Developer/Tools';
my $restoolpath = ( -d $tools43 ) ? $tools43 : '/Developer/Tools';

sub get_flags {
  my $this = shift;
  my %config = $this->SUPER::get_flags;
  
  if ($config{CC} =~ /clang\+\+/ || $config{LD} =~ /clang\+\+/) {
	my $sdkrepl = '';
    # Get ahead with the xcode versions. It'll be wrong, but better than not
    # finding at all.
	for my $sdkversion ( qw( 10.14 10.13 10.12 10.11 10.10 10.9 10.8 10.7 10.6 ) ) {
	  my $macossdk = qq(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX${sdkversion}.sdk);
	  if( -d $macossdk ) {
		$sdkrepl = 'clang++ -isysroot ' . $macossdk . ' -stdlib=libc++';
		last;
	  }
	}
	if ( $sdkrepl ) {
	  $config{CC} =~ s/clang\+\+/$sdkrepl/g;
	  $config{LD} =~ s/clang\+\+/$sdkrepl/g;
	}
  }
  return %config;
}

This definitely needs fixing.

Note: See TracTickets for help on using tickets.