search

iains / gcc-10-branch

[April 2021] 10.3 plus Darwin additions, initial 10.3 Arm64.
GNU General Public License v2.0
7 stars 2 forks source link

Not configuring on Sorbet with Macports versions of gmp, mpfr and mpc. #7

Open iAmInActions opened 2 years ago

iAmInActions commented 2 years ago

I was trying to compile under Sorbet Leopard on a G4 and am not getting past the configuration part. It gives the following error:

configure: error: Building GCC requires GMP 4.2+, MPFR 3.1.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations.  Source code for these libraries can be found at
their respective hosting sites as well as at
https://gcc.gnu.org/pub/gcc/infrastructure/.  See also
http://gcc.gnu.org/install/prerequisites.html for additional info.  If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files.  They may be located in separate packages.

I have installed the dependencies using sudo port install gmp mpfr libmpc.

Any ideas why it fails?

barracuda156 commented 2 years ago

Any ideas why it fails?

  1. (Hope @iains excuses me for replying first.) What exactly are you trying to do? If you want to build gcc10 from here, you don’t need to use Macports at all. You should download dependencies using gcc own script, and then they will be taken care of by the build. If you build gcc10 inside Macports, just use gcc10-bootstrap port. Once you build gcc10-bootstrap (and that should be easy, no dependencies, just install Xcode 3.1.4), then you can proceed with building a complete gcc11. It will require manual changes to portfiles though. Macports won’t let you build gcc10 or gcc11 on 10.5.8 otherwise.
  2. Perhaps it makes sense to specify what “Sorbet Leopard” is. It is a tweaked version of 10.5.8 by some folks from Macrumors. (I am afraid you won’t get much specific support for it btw.)
iains commented 2 years ago

I was trying to compile under Sorbet Leopard on a G4 and am not getting past the configuration part. It gives the following error:

configure: error: Building GCC requires GMP 4.2+, MPFR 3.1.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations.  Source code for these libraries can be found at
their respective hosting sites as well as at
https://gcc.gnu.org/pub/gcc/infrastructure/.  See also
http://gcc.gnu.org/install/prerequisites.html for additional info.  If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files.  They may be located in separate packages.

I have installed the dependencies using sudo port install gmp mpfr libmpc.

Any ideas why it fails?

Well, it's a guess, but that would indicate that the configure cannot 'see' the installed gmp mpfr and mpc - assuming that the installed versions of these packages are acceptable.

Sorry, that I cannot really help much with the internals of macports - see @barracuda156's points.

iAmInActions commented 2 years ago

It will require manual changes to portfiles though. Macports won’t let you build gcc10 or gcc11 on 10.5.8 otherwise.

Where are those located and what will I have to change?

2. Perhaps it makes sense to specify what “Sorbet Leopard” is. It is a tweaked version of 10.5.8 by some folks from Macrumors. (I am afraid you won’t get much specific support for it btw.)

Sorbet Leopard is a pre-packaged Leopard image available on macintosh garden that has some optimisation features, cosmetic changes and a few upgraded libraries. It should be fully compatible with regular 10.5.8.

Edit: Sorry if I'm a bit annoying, I'm pretty new to OS X and mac ports so I am not that familiar with the internals of it yet.

iAmInActions commented 2 years ago

Figured out how to do it using this tutorial: https://trac.macports.org/wiki/howto/PatchLocal

It now works fine. Thanks for your help @barracuda156 and @iains!

Note: I will keep the issue open for now just in case I encounter further issues but if it continues working I'll close it in a few days.

barracuda156 commented 2 years ago

It will require manual changes to portfiles though. Macports won’t let you build gcc10 or gcc11 on 10.5.8 otherwise.

Where are those located and what will I have to change?

  1. Build this: https://ports.macports.org/port/gcc10-bootstrap (for 10.5.8 no changes needed if you build for ppc; if you build for ppc64 or universal, it may not work – for me the last revision 5 failed, while original did build; notice that the port forces +universal as default, so unless it is what you want, disable it by sudo port -v install gcc10-bootstrap -universal).
  2. Follow instructions in gcc10-bootstrap portfile: add specified lined to gcc11 portfile in order to build it with gcc10-bootstrap. Remove a ban of darwin9 in gcc11 portfile. Remove jit, it fails to build (you will find a line that enables jit for anything but i386 – either delete it or change to ppc). Remove a ban of gcc-4* – this should enable using gcc10-bootstrap, otherwise Macports may complain. It is a bug in Macports, IMO. Build libgcc11 first, then build gcc11.
  3. Change a setting in libgcc portfile and in compilers-1.0.tcl portgroup to make libgcc11 default for darwin9 (you need to modify conditional there).
  4. Rebuild libgcc port, so that it uses libgcc11.
  5. Change settings in gcc_compilers.tcl in compilers folder, so that your new gcc11 is actually invoked as a default compiler. Otherwise it is disabled for Leopard and Tiger and Macports won’t use it. Alternatively, you will need to manually invoke it with sudo port -v install PORT configure.compiler=macports-gcc-11.
  6. Upgrading to gcc11 will break gcc7 which you may have had in Macports, and you will have to rebuild all ports that depended on gcc7 with gcc11 (mpich and friends, for instance).
  7. Every sudo port -v sync overrides settings in portgroups, so you will want to make a copy in a local port repo and symlink compilers folder and compilers-1.0.tcl every time following a sync. Yes, it is a pain.
  8. If anything fails for 10.5.8, open a ticket here: https://trac.macports.org/

Sorbet Leopard is a pre-packaged Leopard image available on macintosh garden that has some optimisation features, cosmetic changes and a few upgraded libraries. It should be fully compatible with regular 10.5.8.

It is from here: https://forums.macrumors.com/threads/sorbet-leopard-your-power-mac-unleashed-revision-1-5-released.2300924/ Macintosh Garden is just a repo used to store an image.

kencu commented 2 years ago

Although no one is asking me, I will volunteer a thought:

The single best way forward for users of PowerPC Macs who want to stick with running MacOS would be for everyone -- every single person -- to install 10.5.8 (or 10.4.11 if they prefer) and leave their system absolutely stock in that fashion.

Then everyone should converge on the best package manager that offers to continue supporting them -- currently I would say that is MacPorts -- and work together to come up with toolchain fixes and software fixes (portfile fixes) that work properly through MacPorts' well-tested, robust, and reproducible build methods.

If there is a need for new toolchain parts to be installed into the system, MacPorts has that capability and does it now, using the libcxx port for example. If there is a nice version of Safari that can be built, do it in MacPorts. If there is a binary of something that is not possible to build, MacPorts can install it.

This wild mishmash of different system flavours is somewhat interesting to play with and can be fun, and there is certainly nothing wrong with that, but (IMHO) that is not a path forward for real use, whereas MacPorts truly is such a path.

barracuda156 commented 2 years ago

@kencu On a side-note, we don’t have a port to build TenFourFox, do we? If no, why not? The method is supposedly explicit.

kencu commented 2 years ago

I do in fact have a TenFourFox port that I used to generate all the TenFourFox binaries I uploaded to the TenFourFox download site when I was providing all those Intel TenFourFox binaries for all those years I did it.

iains commented 2 years ago

AFAIU, the main problem with browsers is having a usable set of certificates on the system, since most of those installed have now expired - probably even the stock Safari would work better then.

kencu commented 2 years ago

Here is the TenFourFox macports port repo. Needs updating, but the portfile worked last time I used it. I started building manually at a certain point, as I could just do an incremental build instead of starting from scratch all the time.

https://github.com/kencu/tenfourfox-macports

kencu commented 2 years ago

AFAIU, the main problem with browsers is having a usable set of certificates on the system, since most of those installed have now expired - probably even the stock Safari would work better then.

And they are limited to TLS 1.1.

For this issue, the simplest path forward that leaves the system alone would be to use the squid proxy that does https rewriting. That comes from a separate source right now, but would be best and simple to build using a MacPorts portfile instead, for all users to use automatically.

I replaced the certs in my 10.6.8 system with the ones from a much newer system manually. But there again, that could be done with a MacPorts portfile that archives the old ones and installs the new ones, so everyone gets the exact same set.

Anyway, I have moved on to Linux on PPC, but just trying to be helpful to those here who still like to run MacOS 10.4 and 10.5 on PPC.

barracuda156 commented 2 years ago

@kencu Thank you!

BTW, there is TLS 1.3, apparently: https://forums.macrumors.com/threads/updated-12-23-2020-100-modern-up-to-date-tls-1-3-enabled-web-browser-for-panther-snow-leopard-links2.2231286/

kencu commented 2 years ago

tenfourfox has TLS 1.3 too thankfully.

barracuda156 commented 2 years ago

@kencu Ah, sorry, I misunderstood you. Thanks.

By the way, is updating certs something trivial to do? Apparently certs are available through 2022: https://curl.se/docs/caextract.html Can I just pick those and install into 10.5.8/10.6?

kencu commented 2 years ago

I did something like this last year, when Let's Encrypt cert expired causing about 1 million websites to fail:

https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi

barracuda156 commented 2 years ago

@kencu Besides on TFF, I will hopefully fix processor identification for PPC to enable it, but is it actually required to use gcc48? Or just nobody tried using later gcc, so it cannot be confirmed to work?

kencu commented 2 years ago

It was confirmed that no later gcc version will work, last check, when a number of us tried.

Look through the issues on TFF from about 2018/2019 when I tried newer gcc versions back then.

barracuda156 commented 2 years ago

It was confirmed that no later gcc version will work, last check, when a number of us tried.

Look through the issues on TFF from about 2018/2019 when I tried newer gcc versions back then.

Thank you! (Super-strange, by the way. I thought that later gcc will always build what an earlier can.)

kencu commented 2 years ago

In general, newer versions of compilers (gcc, clang, all of them) become ever more strict about requiring standards to be upheld.... shepherding the flock along, as it were.

The usual thing is for older software that is not being continuously upgraded to break with newer compilers, rather than be improved by them.

Which is why there was never any rush to move the older PPC systems on MacPorts from gcc7 to gcc10 or gcc11 -- no advantage, lots of breakage. Although we may now be reaching the limits of gcc7's ability to build the newest software -- there are goalposts at each end of the playing field here.

barracuda156 commented 2 years ago

In general, newer versions of compilers (gcc, clang, all of them) become ever more strict about requiring standards to be upheld.... shepherding the flock along, as it were.

The usual thing is for older software that is not being continuously upgraded to break with newer compilers, rather than be improved by them.

Which is why there was never any rush to move the older PPC systems on MacPorts from gcc7 to gcc10 or gcc11 -- no advantage, lots of breakage. Although we may now be reaching the limits of gcc7's ability to build the newest software -- there are goalposts at each end of the playing field here.

BTW, after the latest update of libgcc11, due to a change of dylibs structure, all earlier gcc (in Macports) are broken, they do not find dylibs they were used to. Is this issue solved somehow for Intel systems? (I do not expect ppc be any different here, TBH.)

kencu commented 2 years ago

One dylib that used to be provided by libgcc 11.2.0 is not provided by libgcc 11.3.0, so we changed libgcc10 to provide it.

It's possible that because you have gone rather off-piste with respect to your gcc versions, you didn't pick that up.

At least I believe that is likely your issue, as I have heard of no other.

barracuda156 commented 2 years ago

One dylib that used to be provided by libgcc 11.2.0 is not provided by libgcc 11.3.0, so we changed libgcc10 to provide it.

It's possible that because you have gone rather off-piste with respect to your gcc versions, you didn't pick that up.

At least I believe that is likely your issue, as I have heard of no other.

The only way my gcc and libgcc differ on 10.6 are changes similar to what you have done for gcc7 in darwin.h (and on Leopard, of course, these changes were not made). Other than that, well, a small fix from @iains in darwin.c (mismatching types) and --with-tune-cpu=G5 in config.args.

I have not yet rebuilt libgcc10 however. Maybe that is the reason.

kencu commented 2 years ago

One dylib that used to be provided by libgcc 11.2.0 is not provided by libgcc 11.3.0, so we changed libgcc10 to provide it.

Which one is that?

kencu commented 2 years ago

By "off piste" I am referring to you upgrading your personal systems to use gcc11/libgcc11. There are other things, for example this libgcc10 change, that will then have to be kept track of specifically by you, or your systems will appear to be broken (or be broken perhaps, one never knows).

kencu commented 2 years ago

One dylib that used to be provided by libgcc 11.2.0 is not provided by libgcc 11.3.0, so we changed libgcc10 to provide it.

Which one is that?

  • and please let me know about these things first
  • so that we have a chance to fix the problems properly rather than working around them.

these ones seemed to disappear:

libgcc_ext.10.[4-5].dylib

pls see:

https://trac.macports.org/ticket/65055

iains commented 2 years ago

hmm how is some built object referencing those libraries directly?

===

If you want to keep an older compiler around (that does use libgcc_ext.10.[4-5].dylib) then you must not, of course, delete them when you install the new one since the link lines of the old compiler will use them.

I will try to take a look at the ticket later ...

iains commented 2 years ago

actually, with the improvements we have now made to the libgcc stuff, you can just symlink libgcc_ext.10.[4-5].dylib => /compiler/install/path/lib/libgcc_s.1.1.dylib note the 1.1

(I just confirmed on powerpc-darwin9 and x86_64-darwin18 as spot-checks that this does do the right thing)

barracuda156 commented 2 years ago

actually, with the improvements we have now made to the libgcc stuff, you can just symlink libgcc_ext.10.[4-5].dylib => /compiler/install/path/lib/libgcc_s.1.1.dylib note the 1.1

  • which should actually make the older compiler better behaved w.r.t EH too.

@iains So rather than restoring those two dylibs from 11.2.0, better just make symlinks?

iains commented 2 years ago

actually, with the improvements we have now made to the libgcc stuff, you can just symlink libgcc_ext.10.[4-5].dylib => /compiler/install/path/lib/libgcc_s.1.1.dylib note the 1.1

  • which should actually make the older compiler better behaved w.r.t EH too.

@iains So rather than restoring those two dylibs from 11.2.0, better just make symlinks?

not for me to say, I'm just pointing out that (in this particular, very special, case where the libgcc_ext.xx.y.dylib is an export stub) the second solution would work (and could well result in better compatibility with the OS than the old one, since this was part of fixing a long-term problem).

The idea is not something one can consider to be generally applicable to a "normal" dylib.

iains commented 2 years ago

@iAmInActions @barracuda156 @evanphx

Please try the https://github.com/iains/gcc-10-branch/tree/gcc-10-4-darwin-pre-r0 branch which is a preview of the 10.4 release. I'd like to make sure that we get any outstanding issues with the older Darwin boxes sorted out here.

I have bootstrapped on i686/powerpc darwin9, x86_64-darwin-10...21 and build cross and native cross compilers for arm64 on x86_64-darwin20.

NOTE; for darwin8 you will no doubt require at least gcc-4.2 / ld-64-85.2.1 (and possibly cctools assembler from Xcode 3.1.4) in order build these newer branches.

barracuda156 commented 2 years ago

Please try the https://github.com/iains/gcc-10-branch/tree/gcc-10-4-darwin-pre-r0 branch which is a preview of the 10.4 release. I'd like to make sure that we get any outstanding issues with the older Darwin boxes sorted out here.

@iains Thank you! I will definitely do that, however I am likely back to my PPC hardware only in the beginning of August. (Out of Taiwan at the moment, and only have an Intel MBP with me.)

I see that you have included your fix in darwin.c for Rosetta build: int fcode = DECL_MD_FUNCTION_CODE (fndecl);. But this bug has not been addressed yet, right? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522

P. S. Somewhat off-topic: I remember you have mentioned that you installed 10.6 PPC build (10A96?), have you tried to build gcc10 on it? I know it is not supported, just curious. As for me, I could not build gcc10 on 10A190 in a “stand-alone” manner, but in Macports it does build now, as well as gcc11.

iains commented 2 years ago

Please try the https://github.com/iains/gcc-10-branch/tree/gcc-10-4-darwin-pre-r0 branch which is a preview of the 10.4 release. I'd like to make sure that we get any outstanding issues with the older Darwin boxes sorted out here.

@iains Thank you! I will definitely do that, however I am likely back to my PPC hardware only in the beginning of August. (Out of Taiwan at the moment, and only have an Intel MBP with me.)

I see that you have included your fix in darwin.c for Rosetta build: int fcode = DECL_MD_FUNCTION_CODE (fndecl);. But this bug has not been addressed yet, right? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522

nope. not yet - not had time.

P. S. Somewhat off-topic: I remember you have mentioned that you installed 10.6 PPC build (10A96?), have you tried to build gcc10 on it?

I have not done anything with it - TBH it's not interesting to me since it does not support PPC64.