Skip to content
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

Merged
merged 13 commits into from
Jan 9, 2020

Conversation

Ionic
Copy link
Member

@Ionic Ionic commented Dec 7, 2019

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 of go, 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.

…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-)
@kencu
Copy link
Contributor

kencu commented Dec 7, 2019

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

@Ionic
Copy link
Member Author

Ionic commented Dec 8, 2019

Might be the same issue as with go, but I really don't know what libuv does.

Sorry that it took me so long to actually properly PR this.

Copy link
Contributor

@kencu kencu left a 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.

@kencu kencu merged commit 9f937e7 into macports:master Jan 9, 2020
@Ionic
Copy link
Member Author

Ionic commented Jan 14, 2020

Argh, missed the notification here. Okay, will need to get the -devel port up to speed soon.

@Ionic
Copy link
Member Author

Ionic commented Jan 15, 2020

-devel subport updated. Check to see if you like it.

Once the software gets a proper release, we can merge the behavior together again (keeping only the newer behavior in the Portfile) and I can finally get the go port working again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants