mysql57 @5.7.17: error: no member named 'ifr_ifrn' in 'ifreq'

[dgelmer]

mysql57 fails to build.

Hardware: 
  Model Name:	Xserve
  Model Identifier:	Xserve2,1
  Processor Name:	Quad-Core Intel Xeon
  Processor Speed:	2.8 GHz
  Number of Processors:	1
  Total Number of Cores:	4
  L2 Cache:	12 MB
  Memory:	8 GB
  Bus Speed:	1.6 GHz
  Boot ROM Version:	XS21.006C.B06
  SMC Version (system):	1.26f3
  LOM Revision:	1.1.2

OS version: MacOS 10.7.5 (11G63)

Developer Information:

  Version:	4.6.3 (4H1503)
  Location:	/Applications/Xcode.app
  Applications:
  Xcode:	4.6.3 (2068)
  Instruments:	4.6 (46000)
  SDKs:
  Mac OS X:
  10.7:	(11E52)
  10.8:	(12D75)
  iPhone OS:
  6.1:	(10B141)
  iPhone Simulator:
  6.1:	(10B141)

[dgelmer]

install output log

[Schamschula (Marius Schamschula)]

In the future, please the maintainer to the CC field. In this case port info --maintainer mysq57.

Upstream (Oracle) does not support older macOS versions (mysql 5.7 is distributed for Sierra, but are labeled as compatible with El Capitan), so things are likely to be broken for Lion.

[dgelmer]

Sorry. I read that in the instructions then forgot to add it and couldn't figure out how to add it as a modification.

The machine in question is currently running mysql 5.7.16 which was installed via MacPorts 2.4.0

[ryandesign (Ryan Carsten Schmidt)]

.../rapid/plugin/group_replication/libmysqlgcs/src/bindings/xcom/gcs_xcom_networking.cc:86:28: error: no member named 'ifr_ifrn' in 'ifreq'; did you mean 'ifr_ifru'?
  std::string res= ifrecc->ifr_ifrn.ifrn_name;
                           ^~~~~~~~
                           ifr_ifru
/usr/include/net/if.h:315:4: note: 'ifr_ifru' declared here
        } ifr_ifru;
          ^

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #56270.

[mf2k (Frank Schima)]

See #57827

[chrstphrchvz (Christopher Chavez)]

Something is going wrong during configuration on 10.8 and earlier, where CMake thinks the system's …/usr/include/net/if.h doesn't have ifr_name in struct ifreq:

---> Configuring mysql57
⁝
-- Performing Test HAVE_STRUCT_IFREQ_IFR_NAME
-- Performing Test HAVE_STRUCT_IFREQ_IFR_NAME - Failed

…even though it likely always has on macOS (at least ​since 10.1.5):

struct  ifreq {
        /* ⁝ */
        char    ifr_name[IFNAMSIZ];             /* if name, e.g. "en0" */
        /* ⁝ */
        } ifr_ifru;

As a result HAVE_STRUCT_IFREQ_IFR_NAME doesn't get defined, and compiling gcs_xcom_networking.cc uses the wrong code block and fails:

#ifdef HAVE_STRUCT_IFREQ_IFR_NAME
  std::string res= ifrecc->ifr_name;
#else
  std::string res= ifrecc->ifr_ifrn.ifrn_name;
#endif /* HAVE_STRUCT_IFREQ_IFR_NAME */

This might be easy to patch or work around.

[kencu (Ken)]

Yes, looks broken before 10.9 <​https://ports.macports.org/port/mysql57/summary>, but do you need to use that old version?

mysql8 has pretty good across the board building <​https://ports.macports.org/port/mysql8/summary> and I'm using it on 10.6.8 myself, so it builds there too (despite what the summary page says):

$ port -v installed mysql8
The following ports are currently installed:
  mysql8 @8.0.17_2 platform='darwin 10' archs='x86_64' date='2019-10-22T00:15:04-0700'
  mysql8 @8.0.18_0 platform='darwin 10' archs='x86_64' date='2019-12-12T23:58:27-0800'
  mysql8 @8.0.19_0 platform='darwin 10' archs='x86_64' date='2020-01-26T19:04:33-0800'

[chrstphrchvz (Christopher Chavez)]

Replying to kencu:

Yes, looks broken before 10.9 <​https://ports.macports.org/port/mysql57/summary>, but do you need to use that old version?

I personally do not need any version of MySQL from MacPorts at the moment—just chiming in with what I was able to spend a few minutes looking into. It would be nice to get rid of the really old MySQL versions, but there are simply too many dependent ports and port variants (of which any current users need to first be migrated away from) to want to do anything about it.

[chrstphrchvz (Christopher Chavez)]

I have a pull request open to try fixing this: ​https://github.com/macports/macports-ports/pull/7350 . If someone with access to 10.8 or earlier can try it and report the results, that would be appreciated. Otherwise I can wait for the PR to be merged and then tried out by the builders.

[chrstphrchvz (Christopher Chavez)]

Replying to chrstphrchvz:

I have a pull request open to try fixing this: ​https://github.com/macports/macports-ports/pull/7350

PR closed in favor of a possible approach using legacysupport PG: [ea4b467559/macports-legacy-support].

The PR has some insightful comments investigating/explaining this issue from Ken.