Re: git: ca48c22e1c7a - main - lang/gcc12: add gcc 12

------- Original Message -------
On Wednesday, March 1st, 2023 at 12:50 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:


> 
> 
> [ Adding Lorenzo and providing a full quote ]
> 
> On Tue, 10 May 2022, Mark Millard wrote:
> 
> > [Looks like you did not CC Gerald for him to decide
> > if he wanted to comment or to just send a decline to
> > comment.]
> > 
> > On 2022-May-10, at 16:46, Piotr Kubaj pkubaj@anongoth.pl wrote:
> > 
> > > I fixed the first issue.
> > > 
> > > As for the second one, I'm not sure what would be the correct fix (we
> > > could move libgccjit++.h to a non-standard directory, but I'm not sure
> > > about the consequences). Maybe Gerald could offer some insight about
> > > this issue.
> > 
> > If the normal notation is via #include <libgccjit++.h> there
> > might be other places that would just work [absent file name
> > conflicts] and be gcc vintage specific.
> > 
> > But if the normal notation is via #include "libgccjit++.h"
> > then it might not be that easy.
> > 
> > I will also note that, while pkg only reported the one file,
> > there is also a libgccjit.h with the issue as well:
> > 
> > # grep -v % /usr/ports/lang/gcc12/pkg-plist
> > include/libgccjit++.h
> > include/libgccjit.h
> > @postexec if type ccache-update-links >/dev/null 2>&1; then ccache-update-links -v; fi
> > @postunexec if type ccache-update-links >/dev/null 2>&1; then ccache-update-links -v; fi
> > @comment Insert PLIST.lib here
> > 
> > # grep -v % /usr/ports/lang/gcc11/pkg-plist
> > include/libgccjit++.h
> > include/libgccjit.h
> > @postexec if type ccache-update-links >/dev/null 2>&1; then ccache-update-links -v; fi
> > @postunexec if type ccache-update-links >/dev/null 2>&1; then ccache-update-links -v; fi
> > @comment Insert PLIST.lib here
> > 
> > I do not know how much use is made of libgccjit*
> > under FreeBSD.
> > 
> > Looking around it seems that linux contexts seem to
> > deal with such by bundling up libgccjit* material
> > for separate installation so there ends up being
> > either zero or one instance around, despite possibly
> > having multiple gcc* vintages installed.
> 
> 
> Lorenzo has created a fix for this which, sadly, is stuck upstream still:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606450.html

Yes, and unfortunately the same holds for another similar patch that has been
submitted in the following upstream bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 .

I will keep trying to get some attention to the patches.

Cheers,

Lorenzo Salvadore