GCC updated in NetBSD!


Skip to first unread message

Fernando Oleo Blanco's profile photo
unread,
Oct 19, 2021, 5:47:40 PM (22 hours ago) Oct 19
Sign in to reply to author
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
Hello everybody! I bring good news! GCC with Ada support has been updated in NetBSD! Now versions 10 and 11 should work on x86 and x86_64 NetBSD machines! You can find them in pkgsrc-wip (gcc10-aux) [1] and Ravenports (gcc11)

[http://www.ravenports.com/]!

First things first, the acknowledgements: a big thank you goes to J. Marino who did the original gcc-aux packages and who provided most if not all the work when it came to fixing the threads and symbols. Another big thank you goes to tobiasu who correctly picked up that the pthread structure wrappers were not correct and had to be remade. Another big thank you goes to Jay Patelani for his help with pkgsrc. So, long story short. Most of the work that had been done up until a few weeks ago was done correctly, but the failing tests (most related to tasking) were failing in very strange ways. It happened that the pthread structure memory that the Ada wrapper was using was incorrect, so we were getting completely erratic behaviour. Once that got fixed, pretty much all tests passed. J. Marino also took the time and effort to create __gnat_* function wrappers to all the symbols that the NetBSD people have renamed. This is a much cleaner fix and allows for the renamed functions to generate the correct symbols since now they are getting preprocessed. It should also be more "upstream friendly". The issue, however, remains if NetBSD decides to rename more functions that are still being linked directly. There are still some failing ACATS tests (about 10). Some are related to numerical precision and a couple others. They are mostly the same failing tests in both GCC 10 and 11. J. Marino ran the ACATS tests on a DragonflyBSD (or was it FreeBSD?) machine and the same tests were failing there too. So we suspect is is a common limitation on *BSDs and it is unlikely that this will ever affect anybody. There is also the issue of stack unwinding when it contains a signal trampoline [2], read the following thread to gain more information about this.

[1] https://github.com/NetBSD/pkgsrc-wip/tree/master/gcc10-aux


[2] https://mail-index.netbsd.org/tech-kern/2021/10/15/msg027703.html I have started trying to get GCC to xcompile to arm* on NetBSD. I think I am somewhat close, but further hacking on NetBSD's src is needed (and I think the RTS is not getting picked up correctly). So do not get your hopes up. I mean, I have a working gcc x86_64 NetBSD host to NetBSD arm* xcompiler, it is the native gcc on arm* that is not getting built correctly. Regards, -- Fernando Oleo Blanco

https://irvise.xyz


Richard Iswara's profile photo
unread,
1:01 AM (15 hours ago) 1:01 AM
Sign in to reply to author
You do not have permission to delete messages in this group
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
A big applause for your hard work identifying the problem in the first place.
Emmanuel Briot's profile photo
unread,
2:43 AM (13 hours ago) 2:43 AM
Sign in to reply to author
You do not have permission to delete messages in this group
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
When I was working at AdaCore, we used to run our internal CRM and the ticket-management tool that processes all email on a FreeBSD machine, because the sysadmin was very fond of that system. The CRM was (is?) based on AWS (Ada Web Server), so using tasking pretty heavily. We never had any problem at the time. I guess AdaCore has given up on FreeBSD, like they have MacOS. Emmanuel
Simon Wright's profile photo
unread,
9:01 AM (7 hours ago) 9:01 AM
Sign in to reply to author
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
Fernando Oleo Blanco's profile photo
unread,
10:16 AM (5 hours ago) 10:16 AM
Sign in to reply to author
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
Ooops, yes indeed. It needs to be updated, I just copied gcc10 and only cared about it compiling...
Fernando Oleo Blanco's profile photo
unread,
2:44 PM (1 hour ago) 2:44 PM
Sign in to reply to author
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
On 20.10.21 08:43, Emmanuel Briot wrote: > I guess AdaCore has given up on FreeBSD, like they have MacOS. > Emmanuel
Well, GCC officially supports FreeBSD x86* and AFAIK, arm too. Though, AFAIK, the gcc-aux packages from freshports have been left without maintainer... And good news everybody! I have managed to get GPRBuild working and Alire too! I even got the GNATColl components built using Alire ^^. Pretty easy if you ask me :P The mayor issue I am facing now is with make... I tried building AWS with Alire but it could not, since it was using make, which in *BSD world is BSD make, aka, bmake, not GNU make, aka gmake... Anyhow, I am very happy to see so many packages getting built without issues in NetBSD :D There is the problem where GPRBuild says that the "lib" option is not supported on the OS. I don't think it is suprissing since GPRBuild probably does not know anything about NetBSD. I am also getting warnings from gnatmake: /home/fernando/bootstrap_ada/alire/src/alire/alire-toolchains.adb: In function 'Alire.Toolchains.Assistant': /home/fernando/bootstrap_ada/alire/src/alire/alire-toolchains.adb:331:8: warning: frame size too large for reliable stack checking which probably come from NetBSD having a small stack by default.