[MacPorts] #49160: [FWIW] "base" and port:MacPorts fail to build with -flto
#49160: [FWIW] "base" and port:MacPorts fail to build with -flto -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: Keywords: | Port: MacPorts -------------------------+-------------------------------- 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. -- Ticket URL: <https://trac.macports.org/ticket/49160> MacPorts <https://www.macports.org/> Ports system for OS X
#49160: [FWIW] "base" and port:MacPorts fail to build with -flto --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: Resolution: | Keywords: Port: MacPorts | --------------------------+-------------------------------- Comment (by rjvbertin@…): Sorry, forgot some accolades: {{{ main() { char pthread_getattr_np(); char (*f)() = pthread_getattr_np(); return f != pthread_getattr_np; } }}} -- Ticket URL: <https://trac.macports.org/ticket/49160#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#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
participants (1)
-
MacPorts