clang-devel, legacy-support: error: functions that differ only in their return type cannot be overloaded

[ryandesign (Ryan Carsten Schmidt)]

clang-devel failed to build on 10.9 with what might be an error in legacy support:

​https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/247131/steps/install-port/logs/stdio

/opt/local/include/LegacySupport/dirent.h:97:13: error: functions that differ only in their return type cannot be overloaded
extern DIR *fdopendir(int fd) __MPLS_ALIAS_I(fdopendir);
       ~~~~~^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/dirent.h:126:6: note: previous declaration is here
DIR *fdopendir(int) __DARWIN_ALIAS_I(fdopendir);
~~~~~^

[macportsraf]

Can someone test clang-devel on 10.9 with the 10.10 SDK against this version of legacysupport?

​https://github.com/macports/macports-legacy-support/pull/69/commits/f8698e793789e6afce360a17f0d96b934e34e7a0

Note that this is the second last commit in that pull request's commit history, not the last commit. Don't test the last commit. Test the second last commit. Actually, I would like to confirm that the last commit DOESN'T fix the problem. But I'm convinced that it won't, and my idle curiosity isn't worth anyone's valuable time.

This problem was due to the fact that fdopendir in legacysupport never worked properly, and to fix it, a wrapper DIR struct and lots of wrapper functions were created. That meant that when compiling something on 10.9 but with the 10.10 SDK, the fdopendir signatures were different (DIR had different definitions on 10.9 which doesn't have fdopendir, and on 10.10 which does have it).

I don't have 10.9 and wouldn't know how to compile legacysupport's own tests with there the 10.10 SDK anyway, so I can't test it.

Please test this. The same pull request also fixes 10.4 (although there is some debate about that) which has been broken for too long and is waiting for this fix as well.

[programmingkidx]

Well I wasn't sure how you wanted this port tested so I just ran 'sudo port install clang-devel' on Mac OS 10.9. It failed. I wasn't sure what was the error but these messages might have something to do with it:

:info:build /opt/local/bin/libtool: file: CMakeFiles/clang_rt.cc_kext_i386_osx.dir/divmodti4.c.o has no symbols :info:build /opt/local/bin/libtool: file: CMakeFiles/clang_rt.cc_kext_i386_osx.dir/eprintf.c.o has no symbols

The full log is attached.

If you want this port tested is any other way please include step by step directions. Thank you.

[macportsraf]

Hi. The uploaded main.log file only contains errors relating to the PyObject_HEAD_INIT macro. I can't see any errors about "has no symbols". Even so, those errors weren't the errors that lead to this issue (and I don't think that "has no symbols" errors are necessarily a problem - they might just mean that nothing needed to be included in a particular translation unit on the current platform). This issue relates to the fact that the legacysupport implementation of fdopendir has a different function signature up to 10.9 (via the legacysupport library) and from 10.10 onwards (via macOS itself).

And sorry, but I can't provide instructions for how to test this. Maybe @ryandesign can. I don't know how the original problem came about. It was the result of building clang-devel on 10.9 but using the 10.10 SDK (I don't know how to do that, or why you would want to). 10.9 doesn't have fdopendir, so it requires the legacysupport library's implementation, but the 10.10 SDK assumes the existence of fdopendir, and the legacysupport implementation of fdopendir had a different function signature because it had a different definition of the DIR struct, and the multiple function signatures was the cause of the error.

There's a pull request (that's been dragging on for ages) which now has a nice simple implementation of fdopendir that does have the same function signature as the the 10.10+ SDKs. It's dragging on for various reasons, but mainly (I think) because the testing that I'd like to see happen isn't happening, and a lot of the testing that has happened has been with the wrong commit because of an unhelpfully complicated commit history. There's now a single commit, and hopefully it'll soon get merged at least into the devel branch of legacysupport, and more testing will ensue.