Opened 3 years ago

Closed 22 months ago

#55730 closed defect (fixed)

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

Reported by: MartySkinner (Marty Skinner) Owned by: RJVB (René Bertin)
Priority: Normal Milestone:
Component: ports Version: 2.4.2
Keywords: haspatch Cc: dgonyier (Dwaine Gonyier), mojca (Mojca Miklavec)
Port: smartmontools

Description

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.

Attachments (1)

smartmontools.diff (1.5 KB) - added by RJVB (René Bertin) 3 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 3 years ago by mf2k (Frank Schima)

Cc: rjvbertin@… removed
Owner: set to RJVB
Status: newassigned

comment:2 Changed 3 years ago by 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?

comment:3 in reply to:  2 ; Changed 3 years ago by ryandesign (Ryan 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.

comment:4 in reply to:  3 Changed 3 years ago by 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?

comment:5 in reply to:  2 ; Changed 3 years ago by 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.

comment:6 in reply to:  5 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by 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.)

comment:8 Changed 3 years ago by 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.

comment:9 in reply to:  8 Changed 3 years ago by 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.

comment:10 in reply to:  7 Changed 3 years ago by 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++.

Changed 3 years ago by RJVB (René Bertin)

Attachment: smartmontools.diff added

comment:11 Changed 2 years ago by dgonyier (Dwaine Gonyier)

Cc: dgonyier added

comment:12 Changed 22 months ago by ryandesign (Ryan Schmidt)

Cc: mojca added
Keywords: haspatch added
Summary: smartmontools @6.6.0 needs new variant(s) for older systemssmartmontools @7.0: This script was unable to determine a compiler option to enable C++11

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!

comment:13 Changed 22 months ago by 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.

comment:14 Changed 22 months ago by RJVB (René Bertin)

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

comment:15 Changed 22 months ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed

In c4445a3db97fbf6d27d9c770fcf52baf9dc71675/macports-ports (master):

smartmontools: build without c++11 on old systems

closes: #55730

Note: See TracTickets for help on using tickets.