-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
R: updates for packages #24791
R: updates for packages #24791
Conversation
@cjones051073 Any idea what is going on here? Specifically on Sonoma gcc 13.2.0 paths are used which of course fails:
(So everything which uses |
Rebased and rerunning now just to make sure the failure is reproducible. |
@cjones051073 So yes, the usage of wrong paths on Sonoma is reproducible here. |
well clearly the R packages have backed in some way an (internal) version specific path into their builds, which they should not be using. After the update to 13.3.0 that path is of course now
You need to find a way to prevent R from doing this other wise this will happen on every version bump.. |
Perhaps a quick fix would be to rev-bump the R port itself, to force a rebuild of the compiler against the update gcc13 compiler. Note though, gcc14 is now out so perhaps you would want to move to that at the same time. Longer term fix - R should not bake paths like this into its build in the first place. |
@cjones051073 What I do not get is why only Sonoma build fails.
That will require revbumping every R port which uses
Let me try this first. P. S. Locally by the way no issues, and I have updated to gcc 13.3.0 a couple of days before the master branch. |
That is of course a problem in itself. For the vast majority of ports no knowledge of, or need of, the compiler used to build them remains once they are built. The compiler can be updated/removed freely. R is really bad in this regard if it really does force a rebuild of everything just because of a compiler update... |
@cjones051073 In this instance it is MacPorts, AFAIU, since all Fortran-using ports are built as |
That was to prevent issues when new major gcc versions are added and become the 'default' (such as now with gcc14). However, it does not help R if it also has issues with minor updates, like gcc13 going from 13.2 to 13.3. The underlying issue here is with R, not MacPorts. R bakes too much knowledge of the compilers used to build it into itself, such as the example here. This is what needs to be fixed. |
@cjones051073 Revbumping |
For now… as presumably it has now baked a 13.3.0 specific path into itself… Long term this should be fixed, properly, as otherwise you will have this issue on every gcc minor update. |
Yeah, but that is a separate issue to deal with, and not in a hurry. |
@herbygillot @reneeotten This one is good to merge now. |
I believe I pointed out to you 2 years ago exactly where R bakes it the compiler… |
But I don’t recall having issues with minor version before, and even now the issue arose only on arm64. |
Not relevant. The path R is baking in is a private internal one so its GCC's right to do what they want, which includes behaving differently between arm and intel. The bottom line is R should not be doing this, and as @kencu points out this has been brought up before and nothing has been done to address it. |
Description
Updates
Type(s)
Tested on
macOS 10.6
Xcode 3.2
Verification
Have you
port lint --nitpick
?sudo port test
?sudo port -vst install
?