libc-headers installs stdio.h masking OS libc header

[ci42]

See the attached log file.

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

[ryandesign (Ryan Carsten Schmidt)]

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?

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

[ci42]

r101427

[ryandesign (Ryan Carsten Schmidt)]

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?

[neverpanic (Clemens Lang)]

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

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

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

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

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

[larryv (Lawrence Velázquez)]

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

[cooljeanius (Eric Gallager)]

Cc Me!

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

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

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

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

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

[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

[mf2k (Frank Schima)]

This port no longer exists.