Opened 7 years ago

Closed 2 years ago

#37601 closed defect (wontfix)

libc-headers installs stdio.h masking OS libc header

Reported by: ci42 Owned by: mfeiri
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: Cc: lpsinger (Leo Singer), ryandesign (Ryan Schmidt), neverpanic (Clemens Lang), cooljeanius (Eric Gallager), jeremyhu (Jeremy Huddleston Sequoia)
Port: libc-headers

Description

See the attached log file.

@aronnax:
Cc' you, since you committed the update to r9339.

Attachments (1)

main.log (128.7 KB) - added by ci42 7 years ago.

Download all attachments as: .zip

Change History (19)

Changed 7 years ago by ci42

Attachment: main.log added

comment:1 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

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?

comment:2 Changed 7 years ago by ci42

@ryandesign:
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.

comment:3 Changed 7 years ago by ci42

Resolution: fixed
Status: newclosed
Summary: textmate2@r9339: build failstextmate2@r9339: conflicts with libc-headers

comment:4 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: mfeiri@… added
Resolution: fixed
Status: closedreopened

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?

comment:5 Changed 7 years ago by neverpanic (Clemens Lang)

Cc: cal@… added; mfeiri@… removed
Owner: changed from cal@… to mfeiri@…
Port: libc-headers added; textmate2 removed
Status: reopenednew
Summary: textmate2@r9339: conflicts with libc-headerslibc-headers installs stdio.h masking OS libc header

Switched to conflicts_build in r101461. I agree this is a more general problem, though.

comment:6 Changed 7 years ago by cooljeanius (Eric Gallager)

Maybe the headers of libc-headers could get put in a folder that isn't in the header search path by default?

comment:7 Changed 7 years ago 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.

comment:8 in reply to:  7 Changed 7 years ago by ci42

Replying to 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. 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.

comment:9 Changed 7 years ago 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.

comment:10 Changed 7 years ago by larryv (Lawrence Velázquez)

Having libc-headers installed screws with cctools too. See #38124.

comment:11 Changed 7 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:12 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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).

Last edited 7 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:13 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Cc: jeremyhu@… added

Cc Me!

comment:14 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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}?

comment:15 in reply to:  14 ; Changed 7 years ago by cooljeanius (Eric Gallager)

Replying to jeremyhu@…:

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.e. http://lists.macosforge.org/pipermail/macports-dev/2012-April/018483.html and #29172)

Last edited 7 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:16 in reply to:  15 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Replying to egall@…:

Replying to 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.

comment:17 Changed 5 years ago by cooljeanius (Eric Gallager)

libc-headers installs elsewhere as of r117043, meaning that the masking of OS headers described in the OP should no longer be an issue

comment:18 Changed 2 years ago by mf2k (Frank Schima)

Resolution: wontfix
Status: newclosed

This port no longer exists.

Note: See TracTickets for help on using tickets.