[MacPorts] #49160: base fails to build with -flto (was: [FWIW] "base" and port:MacPorts fail to build with -flto)

[MacPorts]

#49160: base fails to build with -flto
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  defect       |     Status:  new
  Priority:  Low          |  Milestone:
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------
Changes (by ryandesign@…):

 * priority:  Normal => Low
 * port:  MacPorts =>


Old description:

> A bug report that has a considerable FYI factor:
>
> Using -flto in the CFLAGS when building MacPorts base or port:MacPorts
> leads to a build error in tcl8.5.15 because the (missing) pthread_np.h
> header file is (inappropriately) included. That's a Unix/Linux-specific
> file, so it seems the platform detection went wrong configuring tcl.
>
> That appears to be because of the test for the availability of the
> pthread*_np functions succeeds because the link-optimiser suppresses the
> actual symbol tested for from the test app. Looking at the test code this
> appears to be something any good optimiser would (or could) do; after
> cleanup the test "payload" looks like this:
>
> main()
> {
>         char pthread_getattr_np();
>         char (*f)() = pthread_getattr_np();
>         return f != pthread_getattr_np;
> }
>
> In other words, the main function should always return true, the actual
> value of the variable (including "undefined") is moot for the test
> result.
>
> I'm aware that this is not a MacPorts bug but an issue in the Tcl build
> system. I'm reporting it here though because it occurs in a possibly
> customised Tcl version ... and I'm hoping at least one "base" developer
> already has a Tcl bug reporter account.

New description:

 A bug report that has a considerable FYI factor:

 Using -flto in the CFLAGS when building MacPorts base or port:MacPorts
 leads to a build error in tcl8.5.15 because the (missing) pthread_np.h
 header file is (inappropriately) included. That's a Unix/Linux-specific
 file, so it seems the platform detection went wrong configuring tcl.

 That appears to be because of the test for the availability of the
 pthread*_np functions succeeds because the link-optimiser suppresses the
 actual symbol tested for from the test app. Looking at the test code this
 appears to be something any good optimiser would (or could) do; after
 cleanup the test "payload" looks like this:

 {{{
 main()
 {
         char pthread_getattr_np();
         char (*f)() = pthread_getattr_np();
         return f != pthread_getattr_np;
 }
 }}}

 In other words, the main function should always return true, the actual
 value of the variable (including "undefined") is moot for the test result.

 I'm aware that this is not a MacPorts bug but an issue in the Tcl build
 system. I'm reporting it here though because it occurs in a possibly
 customised Tcl version ... and I'm hoping at least one "base" developer
 already has a Tcl bug reporter account.

--

Comment:

 As far as I know, the version of tcl bundled with MacPorts is stock, with
 no modifications.

 You should report the bug to the developers of Tcl, because you are the
 one experiencing the problem.

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