smartmontools @7.0: This script was unable to determine a compiler option to enable C++11

[MartySkinner (Marty Skinner)]

The configure stage fails due to a new required option --without-cxx11-option when it cannot determine if c++11 is available: a new test for version 6.6.0. This happens on my 10.6.8 (Snow Leopard) system.

An additional option of --without-nvme-devicescan is also mentioned when running configure by hand so I included it in my build but it may not be necessary as an additional variant.

The Portfile specifies an option of --with-drivedb which is not recognized by configure for this port.

[RJVB (René Bertin)]

Should I understand that --without-cxx11-option should be added for Darwin < 13, i.e.

if {${os.major} < 13} {
    configure.args-append \
        --without-cxx11-option=no
}

Strange though, the configure help text suggests this option is for future versions.

As to the other option: one can wonder why it wasn't renamed to its new name by the helpful soul who upgraded the port O:-)

A propos NVMe:

configure: WARNING:
This version of smartmontools provides NVMe support which is still
EXPERIMENTAL.  NVMe devices are not yet included in smartd.conf
'DEVICESCAN' and 'smartctl --scan' unless '-d nvme' is specified.

I think it's clear that we don't need this - yet. Will such devices even ever be supported on Mac?

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

if {${os.major} < 13} {

The decision should not be based on ${os.major} but rather on ${configure.cxx_stdlib}. If it's libstdc++ then it does not support C++11, otherwise it does.

        --without-cxx11-option=no

Unless this configure script is weird, you would use either --without-cxx11-option or --with-cxx11-option=no.

[RJVB (René Bertin)]

Replying to ryandesign:

The decision should not be based on ${os.major} but rather on ${configure.cxx_stdlib}. If it's libstdc++ then it does not support C++11, otherwise it does.

I seem to recall that configure.cxx_stdlib wasn't always set to something other than an empty string, which would make using it for testing a bit complicated. Is that no longer the case?

As long as the use of C++11 is purely optional I do not want to impose anything for using it or not.

Unless this configure script is weird, you would use either --without-cxx11-option or --with-cxx11-option=no.

Please run configure --help and see for yourself?

[MartySkinner (Marty Skinner)]

Replying to RJVB:

Strange though, the configure help text suggests this option is for future versions.

The help text does not seem to do the option justice: without one of the forms of the option the build summarily fails in my environment. Likely never was noticed during the porting before because the system had c++11 available to it.

I know nothing about it, yet the port for gsmartcontrol includes a PortGroup cxx11 1.1 statement. Maybe that could help simplify things here too—if not now, then for later versions of smartmontools?

A propos NVMe:

EXPERIMENTAL.  NVMe devices are not yet included in smartd.conf
'DEVICESCAN' and 'smartctl --scan' unless '-d nvme' is specified.

I think it's clear that we don't need this - yet. Will such devices even ever be supported on Mac?

As I stated originally, I didn't actually test a build without this... admittedly I just wanted to get a successful build. :) Configure may succeed without it.

[RJVB (René Bertin)]

Replying to MartySkinner:

I know nothing about it, yet the port for gsmartcontrol includes a PortGroup cxx11 1.1 statement. Maybe that could help simplify things here too—if not now, then for later versions of smartmontools?

It is my understanding that the cxx11 PG imposes the libc++ conversion on older (10.8 and earlier) systems. That may be relevant for gsmartcontrol, but AFAIAC it would be way too invasive to require this for software that doesn't *require* C++11.

I think it's clear that we don't need this - yet. Will such devices even ever be supported on Mac?

As I stated originally, I didn't actually test a build without this... admittedly I just wanted to get a successful build. :) Configure may succeed without it.

The build succeeds fine without giving the option on 10.9 . Either way, I cannot test this, so I'm going with the default.

[kencu (Ken)]

It is my understanding that the cxx11 PG imposes the libc++ conversion on older (10.8 and earlier) systems.

On <10.9 the cxx11 1.1 PG modifies the clang call to link against the system libstc++ to redirect it to link against the gcc7 libstdc++ instead (which is c++11 compatible), and use the headers for that library.

It also passes a flag to force the use of several calls to be compatible with the older libstdc++ style of calling, to make it compatible with software built against the older system libstdc++.

(On PPC, if anyone is interested in that, it builds with gcc6 against the libstdc++ from gcc7, again with the compatibility flag.)

[kencu (Ken)]

On my 10.6.8 system, smartmontools installed directly right through without any issues:

$ port -v installed smartmontools
The following ports are currently installed:
  smartmontools @6.6_0+attributelog+savestates (active) platform='darwin 10' archs='x86_64' date='2018-01-23T18:33:38-0800'

I should write up a wiki page on how to set up 10.6.8 for maximum compatibility with MacPorts software.

[MartySkinner (Marty Skinner)]

Replying to kencu:

On my 10.6.8 system, smartmontools installed directly right through without any issues:

$ port -v installed smartmontools
The following ports are currently installed:
  smartmontools @6.6_0+attributelog+savestates (active) platform='darwin 10' archs='x86_64' date='2018-01-23T18:33:38-0800'

Here is my output:

port -v installed smartmontools
The following ports are currently installed:
  smartmontools @6.4_0+attributelog+savestates platform='darwin 10' archs='i386' date='2016-02-23T14:57:51-0500'
  smartmontools @6.5_0+attributelog+savestates platform='darwin 10' archs='i386' date='2016-06-27T08:37:17-0400'
  smartmontools @6.6_0+attributelog+savestates (active) platform='darwin 10' archs='i386' date='2018-01-21T00:05:40-0500'

I should write up a wiki page on how to set up 10.6.8 for maximum compatibility with MacPorts software.

I have loads of ports installed (mostly as dependent items) but would certainly welcome any information to review my setup against an "ideal" environment.

[RJVB (René Bertin)]

Replying to kencu:

On <10.9 the cxx11 1.1 PG modifies the clang call to link against the system libstc++ to redirect it to link against the gcc7 libstdc++ instead (which is c++11 compatible), and use the headers for that library.

Ah, that's news to me. That's more or less what I always did when still on 10.6, but when I brought it up that always led to remarks on how this was certainly problematic because of mixing and (mis)matching libstdc++ versions.

Not that it's directly relevant but maybe I should pick up my pet project to get a -stdlib option into G++ again (the patch should be ready for use in MacPorts) :)

It also passes a flag to force the use of several calls to be compatible with the older libstdc++ style of calling, to make it compatible with software built against the older system libstdc++.

I only see -D_GLIBCXX_USE_CXX11_ABI=0?

BTW:

# GCC compilers can not use libc++

This is not true in the absolute sense. Instructions on how to use libc++ with GCC aren't hard to find, and I already proposed a patch to port:gcc7 that implements those instructions.

If I still had a separate pre-10.9 system I'd try tinkering as follows: 1 install libc++ into $prefix/lib, built following the instructions for Linux, so linking against libstd++/libsupc++ itself 2 add a -stdlib=libc++ option to gcc7

Experience on Linux (using clang 5) hasn't yet exposed any issues, and there I am very likely using libraries originally built against the gcc 4.x, gcc 5, 6 and 7 versions of libstdc++ in a single runtime address space, in addition to libc++.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #56057.

checking for /usr/bin/g++-4.2 option to accept C++11... unknown
configure: error: 
This version of smartmontools does not use C++11 features, but future
versions possibly will.
This script was unable to determine a compiler option to enable C++11.
Use option '--with-cxx11-option=OPTION' to specify the compiler option
(it will be used in the actual build only if '--with-cxx11-regex' is set).
Use option '--without-cxx11-option' to suppress this error message if the
compiler lacks C++11 support.
In both cases, please send info about compiler and platform to
smartmontools-support@listi.jpberlin.de - Thanks!

[kencu (Ken)]

See <​https://github.com/macports/macports-ports/pull/3402>.

For now, any users who are wanting this software and run into this error, please do this:

sudo port -v -N install clang-5.0
sudo port -v install smartmontools configure.compiler=macports-clang-5.0

and you'll be in business while it is sorted out how this is to be fixed.

[RJVB (René Bertin)]

Does port install clang-5.0 somehow address missing C++11 support in the C++ runtime library?

[kencu (Ken)]

In c4445a3db97fbf6d27d9c770fcf52baf9dc71675/macports-ports (master):

smartmontools: build without c++11 on old systems

closes: #55730