-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create fdopendir variations (including ground work for multiple variations support) #24
Conversation
…erate fdopendir() variations. It's important to make best_fchdir() static so that the symbol is only included and usable within its own object file. Otherwise it'll be included multiple times when merging variations, leading to linker errors.
We only need this symbol around once, so don't create multiple duplicated versions of it using the "static" keyword.
Contains the major Darwin version by default.
Can be used to specify an architecture directly and bypass the lipo -archs check, that might require a newer version of cctools than the base system/Xcode/CLTs provide. Mostly only useful for MacPorts. Note that forcing an architecture also requires the compiler to generate single-architecture files. This is not done for technical reasons, since it could equally well be an architecture list and used as such, but for convenience and a safety check when using the muniversal PortGroup within MacPorts.
…rchitecture files for different code variants.
We want: - _fdopendir (32-bit struct stat) - _fdopendir$UNIX2003 (32-bit struct stat, SUS/UNIX conformance) (not on x86_64 or ppc64) - _fdopendir$INODE64 (64-bit struct stat) (not on i386 or ppc or 10.4-) - _fdopendir$INODE64$UNIX2003 (64-bit struct stat with UNIX/SUS-conformance) (not on x86_64 or ppc64 or 10.4-)
…l variables PLATFORM and FORCE_ARCH.
Thanks for all the time you spent to factor this apart so we/I could follow it all more clearly. I appreciate the effort involved as well. It looks mergeable to me. I will download it on a few systems and run the test suite and see what happens. The complexity goes up, naturally, with the added features. I am also running into some headaches with libuv that needs different contructs for the _close command based on the system version (10.4 PPC, 10.5 PPC, and Intel 32bit/64bit all have different _close symbols to be called) so I can see that we might well have more use for this infrastructure once it is in place and working (and I actually understand how to use it!). |
Might be the same issue as with Sorry that it took me so long to actually properly PR this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand all this, and it looks reasonable. I built it and ran the test suite that we have so far on 10.6.8, and it all looks fine. Will proceed with committing this, and we can work on the rest, with @Ionic 's help, to get this over the finish line.
Argh, missed the notification here. Okay, will need to get the |
Once the software gets a proper release, we can merge the behavior together again (keeping only the newer behavior in the |
This PR included support for building multiple variations of specific symbols.
Currently, it only does that for
fdopendir
. One consumer of this are newer versions ofgo
, but you already know that.We will probably need to eventually do this for other
atcalls
as well, but I'm too lazy to check which ones are necessary and refactor (split out) the code to do that. The good part is that this operation should be pretty easy to do, since this PR lays a solid foundation for this sort of things.Also, documentation is added for this new feature (plus a bit of more general documentation that was missing).
Once this is merged, I will update the
legacy-support-devel
port to the new build procedure.