[MacPorts] #37601: textmate2@r9339: build fails
#37601: textmate2@r9339: build fails -------------------------+----------------------- Reporter: ciserlohn@… | Owner: cal@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: textmate2 -------------------------+----------------------- See the attached log file. @aronnax:[[BR]] Cc' you, since you committed the update to {{{r9339}}}. -- Ticket URL: <https://trac.macports.org/ticket/37601> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: textmate2@r9339: build fails --------------------------+------------------- Reporter: ciserlohn@… | Owner: cal@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: textmate2 | --------------------------+------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: It looks very suspicious that you have a file called stdio.h in /opt/local/include: {{{ In file included from /opt/local/include/curl/curl.h:46: /opt/local/include/stdio.h:252:63: error: expected function body after function declarator int fprintf(FILE * __restrict, const char * __restrict, ...) __DARWIN_LDBL_COMPAT(fprintf) __printflike(2, 3); ^ }}} Where did that come from? -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: textmate2@r9339: build fails --------------------------+------------------- Reporter: ciserlohn@… | Owner: cal@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: textmate2 | --------------------------+------------------- Comment (by ciserlohn@…): @ryandesign:[[BR]] You're right. It comes from libc-headers (installed while fixing #37568) {{{ bash-4.2$ port provides /opt/local/include/stdio.h /opt/local/include/stdio.h is provided by: libc-headers }}} Without libc-headers installed texmate2 builds fine - 'conflicts libc- headers' should be added to the portfile. -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: textmate2@r9339: conflicts with libc-headers --------------------------+-------------------- Reporter: ciserlohn@… | Owner: cal@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: fixed | Keywords: Port: textmate2 | --------------------------+-------------------- Changes (by ciserlohn@…): * status: new => closed * resolution: => fixed Comment: r101427 -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: textmate2@r9339: conflicts with libc-headers --------------------------+---------------------- Reporter: ciserlohn@… | Owner: cal@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: textmate2 | --------------------------+---------------------- Changes (by ryandesign@…): * status: closed => reopened * cc: mfeiri@… (added) * resolution: fixed => Comment: The `conflicts` keyword is for activation-time conflicts, i.e. ports that install the same files. That's not the case here; here we have a build- time conflict, for which the `conflicts_build` keyword from the conflicts_build portgroup is used. However, it seems a pretty severe problem for any port to install a header like stdio.h that masks the version the OS provides, especially if its version is not compatible with the system's version. Michael, why does libc-headers need to do that? I would think that would cause a whole lot of ports to fail to build. Can libc-headers not install that file, or can it install it to a different location? -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Changes (by cal@…): * owner: cal@… => mfeiri@… * cc: mfeiri@… (removed) * cc: cal@… (added) * status: reopened => new * port: textmate2 => libc-headers Comment: Switched to `conflicts_build` in r101461. I agree this is a more general problem, though. -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by egall@…): Maybe the headers of libc-headers could get put in a folder that isn't in the header search path by default? -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by mfeiri@…): The whole point of libc-headers is to provide the same files as the OS libc headers. The idea is to allow MacPorts to be selfhosting by providing all the necessary unix tools and headers as ports. Its almost complete, only missing the xnu-headers port. See http://lists.macosforge.org/pipermail/macports-dev/2012-April/018483.html and #29172 for reference. Not sure what the difference is between the headers provided by the libc-headers port and the OS libc headers on that 10.7 machine. I'll try to investigate. -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by ciserlohn@…): Replying to [comment:7 mfeiri@…]:
Not sure what the difference is between the headers provided by the libc-headers port and the OS libc headers on that 10.7 machine. I'll try to investigate.
The difference is that <sys/cdefs.h> (which gets included by stdio.h) is missing in the headers installed by libc-headers. {{{__DARWIN_LDBL_COMPAT}}} is defined in cdefs.h which explains the error shown in [comment:2 comment 2]. I don't know the cpp include machinery good engough to explain why cdefs.h from /usr/include/sys is not used instead. It should be in the include search path. -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by mfeiri@…): I was unable to reproduce this error on my 10.8 machine. But based on your description I assume that this is indeed a case of preprocessor header mixup. I guess you have at least three cdefs.h files on your machine * /usr/include/ * /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/include/sys/cdefs.h * /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/sys/cdefs.h In your case the 10.7 version of stdio.h from libc-headers collided with the 10.8 version of cdefs.h from the MacOSX10.8.sdk. Targeting an SDK that does not match the host OS is more like cross compiling. MacPorts should, just like /usr/include/, stay out of such a cross compilation. The reason why MacPorts headers interfere, while the /usr/include headers don't, is likely because we use CPATH to give MacPorts precedence over other includes. I guess I need to find a way to avoid this when targeting a non- local SDK for "cross" compilation. And I need to commit the xnu-headers port to provide cdefs.h in MacPorts and make sure that the xnu-headers are always installed when libc-headers are present to avoid partial shadowing. -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by larryv@…): Having libc-headers installed screws with cctools too. See #38124. -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by jeremyhu@…): sys/cdefs.h is not part of Libc. It is part of xnu (xnu/bsd/sys/cdefs.h) ... That being said, I removed __DARWIN_LDBL_COMPAT from sys/cdefs.h a while back since it wasn't actually needed any more. It only had an effect on ppc64, so I removed its usage in Libc and then removed the macro from xnu. It seems that the problem is you're somehow using an older Libc (uses the macro) with a newer cdefs.h (macro removed). -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:12> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by jeremyhu@…): I suggest possibly having the libc-headers port also install relevant headers from the corresponding release's xnu, or providing a port that installs the userland headers from xnu, but to be honest, all this seems a bit scary to me ... why not just rely on the host's Libc headers? Why do you feel the need to have a redundant (and less well tested) copy in ${prefix}? -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:14> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by egall@…): Replying to [comment:14 jeremyhu@…]:
I suggest possibly having the libc-headers port also install relevant headers from the corresponding release's xnu, or providing a port that installs the userland headers from xnu, but to be honest, all this seems a bit scary to me ... why not just rely on the host's Libc headers? Why do you feel the need to have a redundant (and less well tested) copy in ${prefix}?
See comment:7 above and the posts it links to -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:15> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by jeremyhu@…): Replying to [comment:15 egall@…]:
Replying to [comment:14 jeremyhu@…]:
I suggest possibly having the libc-headers port also install relevant headers from the corresponding release's xnu, or providing a port that installs the userland headers from xnu, but to be honest, all this seems a bit scary to me ... why not just rely on the host's Libc headers? Why do you feel the need to have a redundant (and less well tested) copy in ${prefix}?
See comment:7 above and the posts that it links to
I don't see how that answers my question. -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:16> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37601: libc-headers installs stdio.h masking OS libc header ---------------------------+---------------------- Reporter: ciserlohn@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: libc-headers | ---------------------------+---------------------- Comment (by egall@…): libc-headers installs elsewhere as of r117043, meaning that the masking of OS headers described in the OP should no longer be an issue -- Ticket URL: <https://trac.macports.org/ticket/37601#comment:17> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts