#38232 closed enhancement (fixed)
Change default compiler variant from +gcc45 to +gcc47
Description
If #33544 was the sequel to #20103, then this makes it a trilogy. Prequels are in the works.
This patch adds +gcc46
and +gcc47
variants to those ports that don’t already have them and changes the default to +gcc47
in those ports that set a default. In the few ports that don’t provide variants, it changes the dependency from port:gcc43
or port:gcc45
to port:gcc47
.
- If this isn’t appropriate for your port(s), say something.
- If GCC 4.7 causes problems for your port(s), say something.
- If I made a typo somewhere or didn’t switch your port(s) over to
[+]gcc47
properly, say something. - If I accidentally added
+gcc46
to a port that needs GCJ, say something becausegcc46
currently doesn’t include GCJ. I tried to keep an eye out for this, butswig-gcj
was the only one I noticed. - If you just want to say hello, say something. Or not.
Attachments (3)
Change History (27)
Changed 12 years ago by larryv (Lawrence Velázquez)
Attachment: | gcc47.diff added |
---|
comment:1 Changed 12 years ago by cooljeanius (Eric Gallager)
Cc: | egall@… added |
---|
comment:2 Changed 12 years ago by cooljeanius (Eric Gallager)
In the few ports that don’t provide variants, it changes the dependency from
port:gcc43
orport:gcc45
toport:gcc47
.
Could these ports get changed to having compiler variants like the rest of the ports?
comment:3 follow-up: 13 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
From the patch, those ports are:
- lua-numlua: the compiler to use needs to be updated in the patch file. Yes, this could be changed so that variants could be added (placeholder in patchfile; reinplace in portfile)
- offlinefs: I'm unable to determine why this port depends on gcc4* at all
- p5-extutils-f77: the patch was already updated to use 4.7, and it too could be changed so that variants could be added
- apbs: yes variants could be added
- apbs-mpi: I'm unable to determine why this port depends on gcc4* at all
- ccpnmr: the patch needs to be updated with the new compiler; yes variants could be added
- ds9: yes variants could be added
- lanHEP: yes variants could be added
- libxc: yes variants could be added
- pdb2pqr: yes variants could be added
comment:4 Changed 12 years ago by michaelld (Michael Dickens)
I just did octave-devel in r103536, along with some other minor changes that needed to be added anyway.
comment:7 Changed 12 years ago by jmroot (Joshua Root)
To quote myself in #33544:
It's best if this happens all at once, as otherwise new installs will tend to get multiple gcc versions during the transition.
comment:8 Changed 12 years ago by lpsinger (Leo Singer)
ds9 is broken. I will change the compiler to gcc47 once it is fixed.
comment:9 Changed 12 years ago by dmeliza@…
jags appears to compile and run fine on gcc47 (tested on i386 Snow Leopard)
comment:10 Changed 12 years ago by Romendakil
whizard works with 4.7. From the next version we wanted to change it into the default compiler anyhow.
comment:12 Changed 12 years ago by kjellpk (Kjell Konis)
Bug #38249 has patches containing version bumps for the R and R-framework (missing from the list of ports for this bug btw) ports and also switches the default compiler to gcc47.
comment:13 Changed 12 years ago by larryv (Lawrence Velázquez)
Regarding variant-less ports:
- lanHEP: Variants added in r103605.
- p5-extutils-f77: Updated with variants in r103606.
- libxc: Variants submitted for consideration in #38260.
- apbs, ccpnmr, pdb2pqr: Variants submitted for consideration in #38261.
- lua-numlua: #38247 will remove the dependency on GCC altogether.
- ds9: Broken as per comment:8; will let maintainer handle it.
What should we do about offlinefs and apbs-mpi? I don’t want to bother adding variants if they don’t need them.
comment:14 Changed 12 years ago by larryv (Lawrence Velázquez)
Port: | R-framework added |
---|---|
Status: | new → assigned |
Just adding R-framework. Also accepting my own ticket.
Changed 12 years ago by larryv (Lawrence Velázquez)
Attachment: | gcc47_2.diff added |
---|
second iteration, after adding variants to several ports
comment:15 Changed 12 years ago by larryv (Lawrence Velázquez)
Update:
- The latest versions of apbs (r104099) and apbs-mpi (r104106) do not require GCC at all.
- I’ve closed #38261, adding variants to ccpnmr (r104107) and pdb2pqr (r104108).
- I’ve closed #38260, updating libxc and adding variants (r104109).
- I’m just going to update offlinefs to require gcc47 and not bother with variants.
New diff attached.
comment:16 follow-up: 17 Changed 12 years ago by cooljeanius (Eric Gallager)
Why is offlinefs the only one that doesn't have compiler variants now? I'd say either add compiler variants to it, or remove the gcc4* dependency entirely, because, as Ryan said, it's unclear how the port even uses gcc4* at all.
comment:17 follow-up: 18 Changed 12 years ago by larryv (Lawrence Velázquez)
Replying to egall@…:
Why is offlinefs the only one that doesn't have compiler variants now? I'd say either add compiler variants to it, or remove the gcc4* dependency entirely, because, as Ryan said, it's unclear how the port even uses gcc4* at all.
I’m not going to add variants just to swap build dependencies. Nor am I going to install fuse4x just to test whether offlinefs builds correctly without GCC present. If you or anyone else wants to verify that GCC is unnecessary, I’d be more than happy to remove the dependency.
Changed 12 years ago by cooljeanius (Eric Gallager)
main.log for my most recent rebuild of offlinefs on Lion
comment:18 follow-up: 19 Changed 12 years ago by cooljeanius (Eric Gallager)
Replying to larryv@…:
Replying to egall@…:
Why is offlinefs the only one that doesn't have compiler variants now? I'd say either add compiler variants to it, or remove the gcc4* dependency entirely, because, as Ryan said, it's unclear how the port even uses gcc4* at all.
I’m not going to add variants just to swap build dependencies. Nor am I going to install fuse4x just to test whether offlinefs builds correctly without GCC present. If you or anyone else wants to verify that GCC is unnecessary, I’d be more than happy to remove the dependency.
Rebuilt offlinefs and attached my main.log from it. I'm currently on Lion, and it just used clang anyway, so I'd say the dependency could be removed.
comment:19 follow-up: 20 Changed 12 years ago by larryv (Lawrence Velázquez)
comment:20 follow-up: 21 Changed 12 years ago by cooljeanius (Eric Gallager)
comment:21 Changed 12 years ago by larryv (Lawrence Velázquez)
Replying to egall@…:
Ok, I rebuilt after this and can confirm that it worked.
Well that really is fascinating, because it failed on all three buildbots.
https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/15895
https://build.macports.org/builders/buildports-lion-x86_64/builds/9402
https://build.macports.org/builders/buildports-mtln-x86_64/builds/3245
In any case, this is off-topic now. #38460.
comment:22 Changed 12 years ago by larryv (Lawrence Velázquez)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Alright, these changes have overstayed their welcome in my tree. Committed in r104220. Thanks for coming, you’ve been a great audience.
comment:23 Changed 11 years ago by blair (Blair Zajac)
Should we do something similar for gcc48 now that 4.8.0 is out?
comment:24 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | blair@… added |
---|
If so, it would be a new ticket, but if you believe this should be done, then you should begin by making a case for it on the mailing list.
Cc Me!