[MacPorts] #67213: libre confgure is broken (and port itself is outdated)

[MacPorts]

#67213: libre confgure is broken (and port itself is outdated)
---------------------------+----------------------
  Reporter:  barracuda156  |      Owner:  alfredh
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.8.1
Resolution:                |   Keywords:  powerpc
      Port:  libre         |
---------------------------+----------------------
Changes (by ryandesign):

 * cc: ryandesign (added)


Comment:

 The port is not `openmaintainer` but we are well past 72 hours from the
 time the ticket was filed with no response from the maintainer so I
 attempted a small fix.

 On Mac OS X 10.6–10.11 on our buildbot workers we see an error about
 missing `clock_gettime`. I added legacysupport to fix that but this was
 ineffective because the port doesn't pass along the MacPorts CFLAGS and
 LDFLAGS to the build system. If the port used the makefile 1.0 portgroup
 that might help, and would eliminate the need for many other lines in the
 Portfile. But as always with custom build systems like this one, the build
 system may need to be patched to meet the expectations of the makefile
 portgroup, or makefile portgroup options may need to be set in the
 portfile.

 Regarding `make: xcrun: Command not found`, the only place in the code
 that runs `xcrun` is in mk/re.mk:

 {{{
         SYSROOT         := $(shell xcrun --show-sdk-path)/usr
 }}}

 However the Portfile sets `SYSROOT` in `build.args` which should override
 whatever value the was set in the Makefile (or the re.mk file it
 includes). I'm surprised `make` bothered to run `xcrun` here since `make`
 knows the value will be overridden, but I recall reading before that
 `make` is very simplistic in how it works. So while the error message is
 not pretty, it shouldn't cause any problem. We could patch re.mk to remove
 the call to `xcrun` to remove the error message.

 Regarding `cc1: error: unrecognized command line option "-std=c11"`, I
 added the C11 requirement to the port, however now that I'm reading the
 code it appears not to require C11 unconditionally. The code in mk/re.mk
 says:

 {{{
 CC_LONGVER  := $(shell $(CC) - --version|head -n 1)
 CC_SHORTVER := $(shell $(CC) -dumpversion)
 CC_MAJORVER := $(shell echo $(CC_SHORTVER) |\
                         sed -e 's/\([0-9]*\)\.[0-9]\+\.[0-9]\+/\1/g')
 }}}
 {{{
 ifneq (,$(findstring gcc, $(CC_LONGVER)))
         CC_NAME := gcc
         CC_VER := $(CC) $(CC_SHORTVER) ($(CC_MAJORVER).x)
         MKDEP := $(CC) -MM
 ifneq ($(CC_MAJORVER), 4)
         CC_C11 := 1
 endif
 endif
 }}}
 {{{
 ifeq ($(CC_NAME),)
 ifneq (,$(findstring clang, $(CC_LONGVER)))
         CC_NAME := clang
         CC_VER := $(CC) $(CC_SHORTVER) ($(CC_MAJORVER).x)
         MKDEP := $(CC) -MM
 ifneq ($(CC_MAJORVER), 4)
         CC_C11 := 1
 endif
 endif
 endif
 }}}
 {{{
 ifeq ($(CC_C11),)
 CFLAGS  += -std=c99
 else
 CFLAGS  += -std=c11
 HAVE_ATOMIC := 1
 endif
 }}}

 So this code is intending to use C99 for gcc 4 and clang 4 and C11
 otherwise. According to [https://github.com/macports/macports-
 base/blob/564391982b671dfc2a30ddd001149cd995bdde25/src/port1.0/portconfigure.tcl#L851-L858
 what we know], C11 should be supported as of Apple clang 5.0, open-source
 clang 3.3, and gcc 4.9. So the only case where this code would try to use
 C11 when that won't work is if the compiler version is less than 4, or if
 it could not determine the compiler version. You didn't attach your log or
 mention what compiler is being used, but you're on PowerPC so I assume
 you're not using clang and I assume you're not trying to use gcc 3 so I
 assume the problem is that it couldn't determine the compiler version.

 It looks like the `sed` command is to blame. It appears to be compatible
 with GNU sed but not BSD sed:

 {{{
 % echo 4.2.1 | sed -e 's/\([0-9]*\)\.[0-9]\+\.[0-9]\+/\1/g'
 4.2.1
 % echo 4.2.1 | gsed -e 's/\([0-9]*\)\.[0-9]\+\.[0-9]\+/\1/g'
 4
 }}}

 Regarding `mk/re.mk:410: Could not detect ARCH`, re.mk does contain code
 for trying to identify the architecture, including some cases for PowerPC,
 but perhaps it requires improvement to identify PowerPC Macs.

 I agree we should begin by updating the port to a newer version. Version 3
 was just released but as suggested by the new major version number it is
 not fully backward compatible so I suggest we start by updating to the
 last version of 2 which is only a few months old.

-- 
Ticket URL: <https://trac.macports.org/ticket/67213#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS