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

R: updates for packages #24791

Merged
merged 28 commits into from
Jul 4, 2024
Merged

R: updates for packages #24791

merged 28 commits into from
Jul 4, 2024

Conversation

barracuda156
Copy link
Contributor

Description

Updates

Type(s)
  • bugfix
  • enhancement
  • security fix
Tested on

macOS 10.6
Xcode 3.2

Verification

Have you

  • followed our Commit Message Guidelines?
  • squashed and minimized your commits?
  • checked that there aren't other open pull requests for the same change?
  • referenced existing tickets on Trac with full URL in commit message?
  • checked your Portfile with port lint --nitpick?
  • tried existing tests with sudo port test?
  • tried a full install with sudo port -vst install?
  • tested basic functionality of all binary files?
  • checked that the Portfile's most important variants haven't been broken?

@barracuda156
Copy link
Contributor Author

@cjones051073 Any idea what is going on here? Specifically on Sonoma gcc 13.2.0 paths are used which of course fails:

  ld: warning: search path '/opt/local/lib/gcc13/gcc/arm64-apple-darwin23/13.2.0' not found
  ld: library 'emutls_w' not found
  clang: error: linker command failed with exit code 1 (use -v to see invocation)

(So everything which uses gfortran does not build.)

@barracuda156
Copy link
Contributor Author

Rebased and rerunning now just to make sure the failure is reproducible.

@barracuda156
Copy link
Contributor Author

@cjones051073 So yes, the usage of wrong paths on Sonoma is reproducible here.

@cjones051073
Copy link
Member

@cjones051073 Any idea what is going on here? Specifically on Sonoma gcc 13.2.0 paths are used which of course fails:

  ld: warning: search path '/opt/local/lib/gcc13/gcc/arm64-apple-darwin23/13.2.0' not found
  ld: library 'emutls_w' not found
  clang: error: linker command failed with exit code 1 (use -v to see invocation)

(So everything which uses gfortran does not build.)

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

Larissa ~/Projects/MacPorts/ports > ls /opt/local/lib/gcc13/gcc/arm64-apple-darwin23/13.3.0
crt3.o			finclude		install-tools		libgcc_eh.a
crtfastmath.o		include			libcaf_single.a		libgcov.a
crttme.o		include-fixed		libemutls_w.a		libheapt_w.a
crttms.o		include-gnu-runtime	libgcc.a		plugin

You need to find a way to prevent R from doing this other wise this will happen on every version bump..

@cjones051073
Copy link
Member

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.

@barracuda156
Copy link
Contributor Author

barracuda156 commented Jul 4, 2024

@cjones051073 What I do not get is why only Sonoma build fails.

Note though, gcc14 is now out so perhaps you would want to move to that at the same time

That will require revbumping every R port which uses gfortran, which is 766 ports.
I am fine with that, but this is a thing to consider.

Perhaps a quick fix would be to rev-bump the R port itself

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.

@cjones051073
Copy link
Member

cjones051073 commented Jul 4, 2024

@cjones051073 What I do not get is why only Sonoma build fails.

Note though, gcc14 is now out so perhaps you would want to move to that at the same time

That will require revbumping every R port which uses gfortran, which is 766 ports. I am fine with that, but this is a thing to consider.

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

@barracuda156
Copy link
Contributor Author

@cjones051073 In this instance it is MacPorts, AFAIU, since all Fortran-using ports are built as +gcc13. (But yeah, it was done this way because of R.)

@cjones051073
Copy link
Member

@cjones051073 In this instance it is MacPorts, AFAIU, since all Fortran-using ports are built as +gcc13. (But yeah, it was done this way because of R.)

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.

@barracuda156
Copy link
Contributor Author

@cjones051073 Revbumping R worked, thankfully.

@cjones051073
Copy link
Member

@cjones051073 Revbumping R worked, thankfully.

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.

@barracuda156
Copy link
Contributor Author

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.

@barracuda156
Copy link
Contributor Author

@herbygillot @reneeotten This one is good to merge now.

@cjones051073 cjones051073 merged commit 46e277b into macports:master Jul 4, 2024
3 checks passed
@barracuda156 barracuda156 deleted the rupd branch July 4, 2024 12:53
@kencu
Copy link
Contributor

kencu commented Jul 4, 2024

I believe I pointed out to you 2 years ago exactly where R bakes it the compiler…

@barracuda156
Copy link
Contributor Author

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.

@cjones051073
Copy link
Member

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.

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

Successfully merging this pull request may close these issues.

4 participants