Why does Mk/Uses/compiler.mk have code for "# clang not always supported on Tier-2" these days?

Mk/Uses/compiler.mk has the .if test : if (defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc) || (${ARCH} != amd64 && ${ARCH} != i386) # clang not always supported on Tier-2 Should it instead allow clang generally these days via instead being: if (defined(FAVORITE_COMPILER) && $

Why does devel/llvm18 not exclude FLANG for armv6? ( devel/llvm17 does exclude FLANG for armv6 )

With "-" for llvm17 and "+" for llvm18, for some reason FLANG is no longer excluded for armv6 (text from a Makefile diff): -OPTIONS_EXCLUDE_armv6+= FLANG OPENMP +OPTIONS_EXCLUDE_armv6+= OPENMP Is this deliberate? === Mark Millard marklmi at yahoo.com

devel/llvm18 on amd64: phase: package "Unable to access file . . ./stage/usr/local/llvm18/lib/clang/18/include/arm_sme.h" more

I attempted a poudriere bulk run based on devel/llvm* using devel/llvm18 and got (amd64 context, no qemu involved: native): === = env: 'PKG_NOTES=build_timestamp ports_top_git_hash ports_top_checkout_unclean port_git_hash port_checkout_unclean b

Re: Why does devel/llvm18 not exclude FLANG for armv6? ( devel/llvm17 does exclude FLANG for armv6 )

On Tue, Feb 06, 2024 at 02:41:32AM -0800, Mark Millard wrote: > With "-" for llvm17 and "+" for llvm18, for some > reason FLANG is no longer excluded for armv6 > (text from a Makefile diff): > > -OPTIONS_EXCLUDE_armv6+= FLANG OPENMP > +OPTIONS_EXCLUDE_armv6+= OPENMP > > Is this deliberate? That

Re: Why does Mk/Uses/compiler.mk have code for "# clang not always supported on Tier-2" these days?

On Tue, Feb 06, 2024 at 02:34:14AM -0800, Mark Millard wrote: > Mk/Uses/compiler.mk has the .if test : > > if (defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc) || > (${ARCH} != amd64 && ${ARCH} != i386) # clang not always supported on Tier-2 > > Should it instead allow clang genera

Re: Why does devel/llvm18 not exclude FLANG for armv6? ( devel/llvm17 does exclude FLANG for armv6 )

On Feb 6, 2024, at 07:38, Brooks Davis wrote: > On Tue, Feb 06, 2024 at 02:41:32AM -0800, Mark Millard wrote: >> With "-" for llvm17 and "+" for llvm18, for some >> reason FLANG is no longer excluded for armv6 >> (text from a Makefile diff): >> >> -OPTIONS_EXCLUDE_armv6+= FLANG OPENMP >> +OPTION

Re: devel/llvm18 on amd64: phase: package "Unable to access file . . ./stage/usr/local/llvm18/lib/clang/18/include/arm_sme.h" more

Just pushed a fix in cf92377ad51eb7e0dbe805e34f5089f7eec89044. -- Brooks On Tue, Feb 06, 2024 at 03:32:28AM -0800, Mark Millard wrote: > I attempted a poudriere bulk run based on devel/llvm* using > devel/llvm18 and got (amd64 context, no qemu involved: native): > > =

For devel/llvm18 context: Bad llvm18 *.so file names? Bad references to llvm18 *.so file names? libLLVM-18.so vs. libLLVM-18rc.so ?

Using BE_STANDRD, I built llvm18 as part of a poudriere bulk run, which resulted in: # ls -Tlod /usr/local/llvm18/lib/libLLVM*.so lrwxr-xr-x 1 root wheel uarch15 Feb 6 13:34:30 2024 /usr/local/llvm18/lib/libLLVM-18.1.0rc.so -> libLLVM-18rc.so -rwxr-xr-x 1 root wheel uarch 138305928 Feb

Re: devel/llvm18 on amd64: phase: package "Unable to access file . . ./stage/usr/local/llvm18/lib/clang/18/include/arm_sme.h" more

On Feb 6, 2024, at 13:22, Brooks Davis wrote: > Just pushed a fix in cf92377ad51eb7e0dbe805e34f5089f7eec89044. Thanks. > -- Brooks > > On Tue, Feb 06, 2024 at 03:32:28AM -0800, Mark Millard wrote: >> I attempted a poudriere bulk run based on devel/llvm* using >> devel/llvm18 and got (amd64 con

Re: For devel/llvm18 context: Bad llvm18 *.so file names? Bad references to llvm18 *.so file names? libLLVM-18.so vs. libLLVM-18rc.so ?

On Feb 6, 2024, at 15:02, Mark Millard wrote: > Using BE_STANDRD, I built llvm18 as part of a poudriere > bulk run, which resulted in: > > # ls -Tlod /usr/local/llvm18/lib/libLLVM*.so > lrwxr-xr-x 1 root wheel uarch15 Feb 6 13:34:30 2024 > /usr/local/llvm18/lib/libLLVM-18.1.0rc.so

Re: For devel/llvm18 context: Bad llvm18 *.so file names? Bad references to llvm18 *.so file names? libLLVM-18.so vs. libLLVM-18rc.so ?

On Feb 6, 2024, at 15:11, Mark Millard wrote: > On Feb 6, 2024, at 15:02, Mark Millard wrote: > >> Using BE_STANDRD, I built llvm18 as part of a poudriere >> bulk run, which resulted in: >> >> # ls -Tlod /usr/local/llvm18/lib/libLLVM*.so >> lrwxr-xr-x 1 root wheel uarch15 Feb 6 13:34

Re: For devel/llvm18 context: Bad llvm18 *.so file names? Bad references to llvm18 *.so file names? libLLVM-18.so vs. libLLVM-18rc.so ?

On Tue, Feb 06, 2024 at 04:22:51PM -0800, Mark Millard wrote: > On Feb 6, 2024, at 15:11, Mark Millard wrote: > > > On Feb 6, 2024, at 15:02, Mark Millard wrote: > > > >> Using BE_STANDRD, I built llvm18 as part of a poudriere > >> bulk run, which resulted in: > >> > >> # ls -Tlod /usr/local/l

Mk/Uses/llvm.mk is going to need _LLVM_MK_VALID_VERSIONS to also list 18

In my testing for early problems for my context by trying to force llvm18 use I ran into the: _LLVM_MK_VALID_VERSIONS= 10 11 12 13 14 15 16 17 that is in Mk/Uses/llvm.mk . === Mark Millard marklmi at yahoo.com

Re: For devel/llvm18 context: Bad llvm18 *.so file names? Bad references to llvm18 *.so file names? libLLVM-18.so vs. libLLVM-18rc.so ?

On Feb 6, 2024, at 16:44, Brooks Davis wrote: > On Tue, Feb 06, 2024 at 04:22:51PM -0800, Mark Millard wrote: >> On Feb 6, 2024, at 15:11, Mark Millard wrote: >> >>> On Feb 6, 2024, at 15:02, Mark Millard wrote: >>> Using BE_STANDRD, I built llvm18 as part of a poudriere bulk run, w

Unmaintained FreeBSD ports which are out of date

Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this po

lang/gcc* broken on current, fix in the works

A late breaking change to my libsys patch caused the MULTILIB option to be broken on current. I've got a fix that seems to be working, but want to do a bit more testing before I commit it as breaking pthreads broadly (vs linkage with GNU ld) would be very bad. For now you can disable MULTILIB as