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

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


> On 22-05-07 14:59:18, Mark Millard wrote:
>> [I ran into another issue for lang/gcc12 use.]
>> 
>> On 2022-May-7, at 12:14, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> I do not know the intent at this point but:
>>> 
>>> /usr/ports/Mk/bsd.gcc.mk
>>> 
>>> still has the lines unchanged that translate lang/gcc12
>>> references into lang/gcc12-devel :
>>> 
>>> # A concrete version has been selected. Set proper ports dependencies,
>>> # CC, CXX, CPP, and flags.
>>> V:=                     ${_USE_GCC:S/.//}
>>> .  if ${V} == 12 || ${V} == 13
>>> _GCC_PORT:=             gcc${V}-devel
>>> .  else
>>> _GCC_PORT:=             gcc${V}
>>> .  endif
>>> 
>>> So, for example, listing lang/gcc12 to poudriere will actually
>>> build lang/gcc12-devel instead.
>> 
>> Note: I'm exploring what happens with the above no longer
>> causing lang/gcc12-devel to be used. No claim that you
>> expect such to be working at this point.
>> 
>> In attempting to install lang/gcc12 I get:
>> 
>> Checking integrity... done (2 conflicting)
>>  - gcc12-12.1.0 conflicts with gcc11-11.3.0 on /usr/local/include/libgccjit++.h
>>  - gcc12-12.1.0 conflicts with gcc11-11.3.0 on /usr/local/include/libgccjit++.h
>> 
>> So I end up with:
>> 
>> Installed packages to be REMOVED:
>> 	gcc11: 11.3.0
>> 
>> New packages to be INSTALLED:
>> 	gcc12: 12.1.0
>> 
>> Because I already had lang/gcc11 installed.
> 
> 

===
Mark Millard
marklmi at yahoo.com