poudriere-devel based llvm16-16.0.0.r3 build got: "pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory"

[Mark Millard]

My poudriere-devel based ports update got:

===
. . .
===>  Building package for llvm16-16.0.0.r3
pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/llvm16

FYI: This was my first time attempting to build llvm16
as one of the ports.

I see that, for example,

http://ampere3.nyi.freebsd.org/build.html?mastername=131arm64-default&build=d0f8db852755

reports success with building (and, so, packaging)
llvm16-16.0.0.r3 . I've no clue why the distinction.

For reference:

port directory: /usr/ports/devel/llvm16
package name: llvm16-16.0.0.r3
building for: FreeBSD CA72_ZFS 13.1-RELEASE-p7 FreeBSD 13.1-RELEASE-p7 arm64
. . .
Poudriere version: poudriere-git-3.3.99.20220831
Host OSVERSION: 1400081
Jail OSVERSION: 1301000

Of 227 ports, this was the only one to fail to build.
llvm15 and gcc12 were built.

This was on a HoneyComb (16 Cortex-A72's).

poudriere-devel is now building ports, targeting main
instead of targeting releng/13.1 . We will see how
that goes building the same 227 ports.

It will be some time before I'll retest building for
releng/13.1 in order to check on repeatability.

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #88 
main-n261230-e78dc78e517a-dirty: Wed Mar  1 16:17:45 PST 2023 
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
 arm64 aarch64 1400081 1400081

===
Mark Millard
marklmi at yahoo.com

Re: poudriere-devel based llvm16-16.0.0.r3 build got: "pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory"

[Tatsuki Makino]

Hello.

I saw it in python relations.
It was due to differences between setuptools and distutils, etc.
For example, bug 265203 of bugzilla.

If not, I don't know :)

Regards.

Re: poudriere-devel based llvm16-16.0.0.r3 build got: "pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory"

[Mark Millard]

On Mar 5, 2023, at 00:03, Mark Millard  wrote:

> My poudriere-devel based ports update got:
> 
> ===
> . . .
> ===>  Building package for llvm16-16.0.0.r3
> pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/devel/llvm16
> 
> FYI: This was my first time attempting to build llvm16
> as one of the ports.
> 
> I see that, for example,
> 
> http://ampere3.nyi.freebsd.org/build.html?mastername=131arm64-default&build=d0f8db852755
> 
> reports success with building (and, so, packaging)
> llvm16-16.0.0.r3 . I've no clue why the distinction.
> 
> For reference:
> 
> port directory: /usr/ports/devel/llvm16
> package name: llvm16-16.0.0.r3
> building for: FreeBSD CA72_ZFS 13.1-RELEASE-p7 FreeBSD 13.1-RELEASE-p7 arm64
> . . .
> Poudriere version: poudriere-git-3.3.99.20220831
> Host OSVERSION: 1400081
> Jail OSVERSION: 1301000
> 
> Of 227 ports, this was the only one to fail to build.
> llvm15 and gcc12 were built.
> 
> This was on a HoneyComb (16 Cortex-A72's).
> 
> poudriere-devel is now building ports, targeting main
> instead of targeting releng/13.1 . We will see how
> that goes building the same 227 ports.
> 
> It will be some time before I'll retest building for
> releng/13.1 in order to check on repeatability.
> 
> # uname -apKU
> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #88 
> main-n261230-e78dc78e517a-dirty: Wed Mar  1 16:17:45 PST 2023 
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
>  arm64 aarch64 1400081 1400081
> 

The build for main also failed.

One difference in my build vs. the FreeBSD build
servers is the use of BE_NATIVE instead of
BE_STANDARD . May be the pkg-plist is mishandled
for BE_NATIVE ?

===
Mark Millard
marklmi at yahoo.com

Re: How do I determine the ABI string used by pkg?

[Dan Langille]

Ian Smith wrote on 3/5/23 12:09 AM:

On 2 March 2023 6:50:13 pm AEDT, Mel Pilgrim  
wrote:
  > I need to determine the ABI string pkg uses on a given system, and
  > need to do so when there are no pkgs installed.

  # pkg -N -vv | grep ABI
Will that install pkg "when there are no pkgs installed", the key 
requirement of the question?


--
Dan Langille
d...@langille.org : https://langille.org/

Re: How do I determine the ABI string used by pkg?

[Kyle Evans]

On Sat, Mar 4, 2023 at 11:10 PM Ian Smith  wrote:
>
> On 2 March 2023 6:50:13 pm AEDT, Mel Pilgrim  
> wrote:
>  > I need to determine the ABI string pkg uses on a given system, and
>  > need to do so when there are no pkgs installed.
>
>  # pkg -N -vv | grep ABI
>
> gets you ABI and ALTABI; the former is the amd64 form, the latter x86:64
>

Note the more concising spelling of this if you know the names (or
need it for, say, scripting):

# pkg config ABI
# pkg config ALTABI

Thanks,

Kyle Evans

Unmaintained FreeBSD ports which are out of date

[portscout]

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 port.
If any ports have already been updated, you can safely ignore the entry.

An e-mail will not be sent again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
cad/ifcopenshell| 0.6.0   | 
blenderbim-230304
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!

RE: How do I determine the ABI string used by pkg?

[Mark Millard]

Mel Pilgrim  wrote on
Date: Thu, 02 Mar 2023 07:50:13 UTC :

> I need to determine the ABI string pkg uses on a given system, and need 
> to do so when there are no pkgs installed.

There may be more to that question than you are expecting
and you may have to establish more about what you want
(and why).

pkg itself is a package and so you have specified it is not
installed. You have not indicated why pkg can not be installed
the normal way and then used. (The question might be if this
can be unblocked or not.)

You have not indicated the range of system versions to be
covered. 12..14? All?

What about when an LP64 architecture is supported for also
running an ILP32 counterpart, so there are 2 ABIs?

LP64  ILP32 counterpart
amd64 i386
powerpc64 powerpc
mips64*   mips*
aarch64   armv6/armv7

(I question the accuracy of the armv6 in the "man 7 arch"
table, although I could change the kernel to switch from
armv7 to armv6 as the counterpart --and once helped someone
build a special kernel that did so.)

So how do you know which ABI you are interested in for
those?

> I've read through libpkg/pkg_elf.c and I can see how it's reading ELF 
> headers from well-known files. That's all easy enough to replicate, but 
> I'm a bit stuck on how it's determining the arch string for x86.

There are also examples like:

# pkg config ABI
FreeBSD:14:armv7

# pkg config ALTABI
freebsd:14:armv7:32:el:eabi:hardfp

Notably, "man 5 pkg.conf" does not even mention ALTABI , just
ABI .

Also, https://pkg.freebsd.org/ only lists the ABI form,
not the ALTABI form. But it does not mention riscv64 ,
riscv64sf , any mips64* , any mips* , sparc64 , 
plain "arm" , armeb , pc98 , ia64 , or alpha at all.

aarch64 is more like amd64:

# pkg config ABI
FreeBSD:14:aarch64

# pkg config ALTABI
freebsd:14:aarch64:64

But I'll note that I used the same machine (without
rebooting) for both armv7 and aarch64 above: armv7
was via a chroot and was without qemu involved (qemu
is not even installed).

Do you always have a already active execution context
to work with that is the one of interest, such as being
in a chroot?

> How/When does pkg decide to use FreeBSD:13:amd64 instead of 
> FreeBSD:13:x86:64?

It might be that it provides ALTABI but makes no use of it?
That would allow other things to make use of the extra
information in ALTABI text.

> Can I safely assume one or the other?

Likely purpose driven, no universal answer otherwise. You
may need to indicate what the ABI ( or ALTABI ) strings
are to be used for.

It used to be that some of the arm variants could be built
for either softfloat or hardfloat. Going back further some
that now have hardfloat instead used a form of softfloat.
It another example of your not having indicated the limits
on your range of interest in the possibilities over FreeBSD's
history.

===
Mark Millard
marklmi at yahoo.com

Re: How do I determine the ABI string used by pkg?

[Mark Millard]

On Mar 5, 2023, at 09:54, Mark Millard  wrote:

> Mel Pilgrim  wrote on
> Date: Thu, 02 Mar 2023 07:50:13 UTC :
> 
>> I need to determine the ABI string pkg uses on a given system, and need 
>> to do so when there are no pkgs installed.
> 
> There may be more to that question than you are expecting
> and you may have to establish more about what you want
> (and why).
> 
> pkg itself is a package and so you have specified it is not
> installed. You have not indicated why pkg can not be installed
> the normal way and then used. (The question might be if this
> can be unblocked or not.)
> 
> You have not indicated the range of system versions to be
> covered. 12..14? All?
> 
> What about when an LP64 architecture is supported for also
> running an ILP32 counterpart, so there are 2 ABIs?
> 
> LP64  ILP32 counterpart
> amd64 i386
> powerpc64 powerpc
> mips64*   mips*
> aarch64   armv6/armv7
> 
> (I question the accuracy of the armv6 in the "man 7 arch"
> table, although I could change the kernel to switch from
> armv7 to armv6 as the counterpart --and once helped someone
> build a special kernel that did so.)
> 
> So how do you know which ABI you are interested in for
> those?
> 
>> I've read through libpkg/pkg_elf.c and I can see how it's reading ELF 
>> headers from well-known files. That's all easy enough to replicate, but 
>> I'm a bit stuck on how it's determining the arch string for x86.
> 
> There are also examples like:
> 
> # pkg config ABI
> FreeBSD:14:armv7
> 
> # pkg config ALTABI
> freebsd:14:armv7:32:el:eabi:hardfp
> 
> Notably, "man 5 pkg.conf" does not even mention ALTABI , just
> ABI .
> 
> Also, https://pkg.freebsd.org/ only lists the ABI form,
> not the ALTABI form. But it does not mention riscv64 ,
> riscv64sf , any mips64* , any mips* , sparc64 , 
> plain "arm" , armeb , pc98 , ia64 , or alpha at all.
> 
> aarch64 is more like amd64:
> 
> # pkg config ABI
> FreeBSD:14:aarch64
> 
> # pkg config ALTABI
> freebsd:14:aarch64:64
> 
> But I'll note that I used the same machine (without
> rebooting) for both armv7 and aarch64 above: armv7
> was via a chroot and was without qemu involved (qemu
> is not even installed).
> 
> Do you always have a already active execution context
> to work with that is the one of interest, such as being
> in a chroot?
> 
>> How/When does pkg decide to use FreeBSD:13:amd64 instead of 
>> FreeBSD:13:x86:64?
> 
> It might be that it provides ALTABI but makes no use of it?
> That would allow other things to make use of the extra
> information in ALTABI text.
> 
>> Can I safely assume one or the other?
> 
> Likely purpose driven, no universal answer otherwise. You
> may need to indicate what the ABI ( or ALTABI ) strings
> are to be used for.
> 
> It used to be that some of the arm variants could be built
> for either softfloat or hardfloat. Going back further some
> that now have hardfloat instead used a form of softfloat.
> It another example of your not having indicated the limits
> on your range of interest in the possibilities over FreeBSD's
> history.

One thing I know is available is kern.supported_archs :

# sysctl kern.supported_archs
kern.supported_archs: aarch64 armv7

(Also, note the lack of armv6 being listed.
The alternate kernel that I mentioned listed
armv6 instead of armv7. The infrastructure
does not allow for listing both as things are.)

So, using that as a source of ARCH names,
each:

FreeBSD:VERSION:A_SUPPORTED_ARCH_NAME

appears to be a valid ABI value on a running system,
and the only valid ABI values for that running system.

I'll note that even when chrooted into a armv7
context on a aarch64 system with AArch32 support:

# sysctl kern.supported_archs
kern.supported_archs: aarch64 armv7

So it does not report specifically on what the chroot
context is for.

===
Mark Millard
marklmi at yahoo.com

Re: How do I determine the ABI string used by pkg?

[Tatsuki Makino]

Uh-huh? :)
You are doing something that doesn't use pkg, so it is going into 
libpkg/pkg_elf.c, right?

Re: poudriere-devel based aarch64 llvm16-16.0.0.r3 build got: bad make -VBE_FREEBSD_PLIST_FILES result leads to "pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory"

[Mark Millard]

[Looks like the problem is not on the pkg side of things.
I adjusted the subject to indicate the newly identified
context as well.]

On Mar 5, 2023, at 01:52, Mark Millard  wrote:

> On Mar 5, 2023, at 00:03, Mark Millard  wrote:
> 
>> My poudriere-devel based ports update got:
>> 
>> ===
>> . . .
>> ===>  Building package for llvm16-16.0.0.r3
>> pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory
>> *** Error code 1
>> 
>> Stop.
>> make: stopped in /usr/ports/devel/llvm16
>> 
>> FYI: This was my first time attempting to build llvm16
>> as one of the ports.
>> 
>> I see that, for example,
>> 
>> http://ampere3.nyi.freebsd.org/build.html?mastername=131arm64-default&build=d0f8db852755
>> 
>> reports success with building (and, so, packaging)
>> llvm16-16.0.0.r3 . I've no clue why the distinction.
>> 
>> For reference:
>> 
>> port directory: /usr/ports/devel/llvm16
>> package name: llvm16-16.0.0.r3
>> building for: FreeBSD CA72_ZFS 13.1-RELEASE-p7 FreeBSD 13.1-RELEASE-p7 arm64
>> . . .
>> Poudriere version: poudriere-git-3.3.99.20220831
>> Host OSVERSION: 1400081
>> Jail OSVERSION: 1301000
>> 
>> Of 227 ports, this was the only one to fail to build.
>> llvm15 and gcc12 were built.
>> 
>> This was on a HoneyComb (16 Cortex-A72's).
>> 
>> poudriere-devel is now building ports, targeting main
>> instead of targeting releng/13.1 . We will see how
>> that goes building the same 227 ports.
>> 
>> It will be some time before I'll retest building for
>> releng/13.1 in order to check on repeatability.
>> 
>> # uname -apKU
>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #88 
>> main-n261230-e78dc78e517a-dirty: Wed Mar  1 16:17:45 PST 2023 
>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
>>  arm64 aarch64 1400081 1400081
>> 
> 
> The build for main also failed.
> 
> One difference in my build vs. the FreeBSD build
> servers is the use of BE_NATIVE instead of
> BE_STANDARD . May be the pkg-plist is mishandled
> for BE_NATIVE ?

I think I finally figured out what to look at to see
the basic problem for devel/llvm16 used via BE_NATIVE
for aarch64 (and, so, arm* as well).

In the below, note the "llvm16/lib/clang/16/include/"
which is a directory

# make -VBE_NATIVE_PLIST_FILES
llvm16/lib/libLLVMAArch64AsmParser.a llvm16/lib/libLLVMAArch64CodeGen.a 
llvm16/lib/libLLVMAArch64Desc.a llvm16/lib/libLLVMAArch64Disassembler.a 
llvm16/lib/libLLVMAArch64Info.a llvm16/lib/libLLVMAArch64Utils.a 
llvm16/lib/libLLVMAMDGPUAsmParser.a llvm16/lib/libLLVMAMDGPUCodeGen.a 
llvm16/lib/libLLVMAMDGPUDesc.a llvm16/lib/libLLVMAMDGPUDisassembler.a 
llvm16/lib/libLLVMAMDGPUInfo.a llvm16/lib/libLLVMAMDGPUTargetMCA.a 
llvm16/lib/libLLVMAMDGPUUtils.a llvm16/lib/libLLVMExegesisAArch64.a 
llvm16/lib/libLLVMWebAssemblyAsmParser.a llvm16/lib/libLLVMWebAssemblyCodeGen.a 
llvm16/lib/libLLVMWebAssemblyDesc.a llvm16/lib/libLLVMWebAssemblyDisassembler.a 
llvm16/lib/libLLVMWebAssemblyInfo.a llvm16/lib/libLLVMWebAssemblyUtils.a  
llvm16/lib/clang/16/include/

(For reference, llvm15 does not end up with a llvm15/lib/clang/15/include/ 
listed.)

By contrast for llvm16, -VBE_FREEBSD_PLIST_FILES ends up listing explicit files
inside the directory:

. . . llvm16/lib/clang/16/include/arm_bf16.h 
llvm16/lib/clang/16/include/arm_cde.h llvm16/lib/clang/16/include/arm_fp16.h 
llvm16/lib/clang/16/include/arm_mve.h llvm16/lib/clang/16/include/arm_neon.h 
llvm16/lib/clang/16/include/arm_sve.h llvm16/lib/clang/16/include/riscv_vector.h

It would appear to me that the llvm16/lib/clang/16/include/arm_*.h files 
possibly
be present for AArch64 because of its coverage of arm* as well, just like for
BE_FREEBSD . (But such does not seem to be the case for devel/llvm15 's 
BE_NATIVE either, so I may be wrong. For both llvm16 and llvm15 , 
_NATIVE_BACKENDS
does not list ARM for aarch64 , just AArch64 . I do not know why since armv7 is
listed in kern.supported_archs: aarch64 armv7 .)

I'll note that there is no _BE_INCS_AArch64 in the Makefile (both llvm16 and 
llvm15)
and there is:

.for BE in FREEBSD NATIVE STANDARD
.for BE_ARCH in ${${BE}_BACKENDS}
_BE_LIBS_${BE}+=${_BE_LIBS_COMMON:S/^/${BE_ARCH}/} \
${_BE_LIBS_${BE_ARCH}:S/^/${BE_ARCH}/} \
${_BE_LIBS_BACKWARDS_${BE_ARCH}:S/$/${BE_ARCH}/}
_BE_INCS_${BE}+=${_BE_INCS_${BE_ARCH}}
.endfor
.endfor

but NATIVE_BACKENDS excludes ARM (in both llvm16 and llvm15).

At least the "llvm16/lib/clang/16/include/" (no file listed) for
-VBE_NATIVE_PLIST_FILES should be eliminated. Possibly the arm_*.h
files under that path should be present.

===
Mark Millard
marklmi at yahoo.com

Re: pkg writing to /

[Kevin Oberman]

On Sat, Mar 4, 2023 at 11:37 PM Daniel Braniss  wrote:

> Hi,
> how can I tell pkg not to write to /? in my case sometimes /
> is mounted ro, and so for example pkg update failed, or
> / - which is usually- kept as small as possible gets filled up, eg
> by /.pkgtemp.compat.x/linux
>
> thanks,
> danny
>

What command are you using? Normally pkg should not be writing to root
unless one of the files it does write to is on the same file system.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: poudriere-devel based aarch64 llvm16-16.0.0.r3 build got: bad make -VBE_FREEBSD_PLIST_FILES result leads to "pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory"

[Mark Millard]

[I found a related partial edit in the llvm16 Makefile.]

On Mar 5, 2023, at 15:53, Mark Millard  wrote:

> [Looks like the problem is not on the pkg side of things.
> I adjusted the subject to indicate the newly identified
> context as well.]
> 
> On Mar 5, 2023, at 01:52, Mark Millard  wrote:
> 
>> On Mar 5, 2023, at 00:03, Mark Millard  wrote:
>> 
>>> My poudriere-devel based ports update got:
>>> 
>>> ===
>>> . . .
>>> ===>  Building package for llvm16-16.0.0.r3
>>> pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory
>>> *** Error code 1
>>> 
>>> Stop.
>>> make: stopped in /usr/ports/devel/llvm16
>>> 
>>> FYI: This was my first time attempting to build llvm16
>>> as one of the ports.
>>> 
>>> I see that, for example,
>>> 
>>> http://ampere3.nyi.freebsd.org/build.html?mastername=131arm64-default&build=d0f8db852755
>>> 
>>> reports success with building (and, so, packaging)
>>> llvm16-16.0.0.r3 . I've no clue why the distinction.
>>> 
>>> For reference:
>>> 
>>> port directory: /usr/ports/devel/llvm16
>>> package name: llvm16-16.0.0.r3
>>> building for: FreeBSD CA72_ZFS 13.1-RELEASE-p7 FreeBSD 13.1-RELEASE-p7 arm64
>>> . . .
>>> Poudriere version: poudriere-git-3.3.99.20220831
>>> Host OSVERSION: 1400081
>>> Jail OSVERSION: 1301000
>>> 
>>> Of 227 ports, this was the only one to fail to build.
>>> llvm15 and gcc12 were built.
>>> 
>>> This was on a HoneyComb (16 Cortex-A72's).
>>> 
>>> poudriere-devel is now building ports, targeting main
>>> instead of targeting releng/13.1 . We will see how
>>> that goes building the same 227 ports.
>>> 
>>> It will be some time before I'll retest building for
>>> releng/13.1 in order to check on repeatability.
>>> 
>>> # uname -apKU
>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #88 
>>> main-n261230-e78dc78e517a-dirty: Wed Mar  1 16:17:45 PST 2023 
>>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
>>>  arm64 aarch64 1400081 1400081
>>> 
>> 
>> The build for main also failed.
>> 
>> One difference in my build vs. the FreeBSD build
>> servers is the use of BE_NATIVE instead of
>> BE_STANDARD . May be the pkg-plist is mishandled
>> for BE_NATIVE ?
> 
> I think I finally figured out what to look at to see
> the basic problem for devel/llvm16 used via BE_NATIVE
> for aarch64 (and, so, arm* as well).
> 
> In the below, note the "llvm16/lib/clang/16/include/"
> which is a directory
> 
> # make -VBE_NATIVE_PLIST_FILES
> llvm16/lib/libLLVMAArch64AsmParser.a llvm16/lib/libLLVMAArch64CodeGen.a 
> llvm16/lib/libLLVMAArch64Desc.a llvm16/lib/libLLVMAArch64Disassembler.a 
> llvm16/lib/libLLVMAArch64Info.a llvm16/lib/libLLVMAArch64Utils.a 
> llvm16/lib/libLLVMAMDGPUAsmParser.a llvm16/lib/libLLVMAMDGPUCodeGen.a 
> llvm16/lib/libLLVMAMDGPUDesc.a llvm16/lib/libLLVMAMDGPUDisassembler.a 
> llvm16/lib/libLLVMAMDGPUInfo.a llvm16/lib/libLLVMAMDGPUTargetMCA.a 
> llvm16/lib/libLLVMAMDGPUUtils.a llvm16/lib/libLLVMExegesisAArch64.a 
> llvm16/lib/libLLVMWebAssemblyAsmParser.a 
> llvm16/lib/libLLVMWebAssemblyCodeGen.a llvm16/lib/libLLVMWebAssemblyDesc.a 
> llvm16/lib/libLLVMWebAssemblyDisassembler.a 
> llvm16/lib/libLLVMWebAssemblyInfo.a llvm16/lib/libLLVMWebAssemblyUtils.a  
> llvm16/lib/clang/16/include/
> 
> (For reference, llvm15 does not end up with a llvm15/lib/clang/15/include/ 
> listed.)
> 
> By contrast for llvm16, -VBE_FREEBSD_PLIST_FILES ends up listing explicit 
> files
> inside the directory:
> 
> . . . llvm16/lib/clang/16/include/arm_bf16.h 
> llvm16/lib/clang/16/include/arm_cde.h llvm16/lib/clang/16/include/arm_fp16.h 
> llvm16/lib/clang/16/include/arm_mve.h llvm16/lib/clang/16/include/arm_neon.h 
> llvm16/lib/clang/16/include/arm_sve.h 
> llvm16/lib/clang/16/include/riscv_vector.h
> 
> It would appear to me that the llvm16/lib/clang/16/include/arm_*.h files 
> possibly
> be present for AArch64 because of its coverage of arm* as well, just like for
> BE_FREEBSD . (But such does not seem to be the case for devel/llvm15 's 
> BE_NATIVE either, so I may be wrong. For both llvm16 and llvm15 , 
> _NATIVE_BACKENDS
> does not list ARM for aarch64 , just AArch64 . I do not know why since armv7 
> is
> listed in kern.supported_archs: aarch64 armv7 .)
> 
> I'll note that there is no _BE_INCS_AArch64 in the Makefile (both llvm16 and 
> llvm15)
> and there is:
> 
> .for BE in FREEBSD NATIVE STANDARD
> .for BE_ARCH in ${${BE}_BACKENDS}
> _BE_LIBS_${BE}+=${_BE_LIBS_COMMON:S/^/${BE_ARCH}/} \
>${_BE_LIBS_${BE_ARCH}:S/^/${BE_ARCH}/} \
>${_BE_LIBS_BACKWARDS_${BE_ARCH}:S/$/${BE_ARCH}/}
> _BE_INCS_${BE}+=${_BE_INCS_${BE_ARCH}}
> .endfor
> .endfor
> 
> but NATIVE_BACKENDS excludes ARM (in both llvm16 and llvm15).
> 
> At least the "llvm16/lib/clang/16/include/" (no file listed) for
> -VBE_NATIVE_PLIST_FILES should be eliminated. Possibly the arm_*.h
> files under that path should be present.

Onl

Re: poudriere-devel based aarch64 llvm16-16.0.0.r3 build got: bad make -VBE_FREEBSD_PLIST_FILES result leads to "pkg-static: pkg_checksum_hash_sha256_file(read failed): Is a directory"

[Mark Millard]

I'm now doing my devel/llvm16 builds via the Makefile changes:
(leading or other whitespace may not be preserved)

diff --git a/devel/llvm16/Makefile b/devel/llvm16/Makefile
index 42b2b24e..a1e4a3ab5f35 100644
--- a/devel/llvm16/Makefile
+++ b/devel/llvm16/Makefile
@@ -117,7 +117,7 @@ BE_STANDARD_DESC=   All non-experimental backends
  BE_WASM_DESC= WebAssembly backend (required by firefox via wasi)
  .for BE in FREEBSD NATIVE STANDARD
  BE_${BE}_PLIST_FILES= 
${_BE_LIBS_${BE}:O:S/$/.a/:S|^|${LLVM_DIR}/lib/libLLVM|} \
-   
${_BE_INCS_${BE}:S|^|${LLVM_DIR}/lib/clang/${LLVM_MAJOR}/include/|:N${LLVM_DIR}/lib/clang/${LLVM_RELEASE}/include/$}
+   
${_BE_INCS_${BE}:S|^|${LLVM_DIR}/lib/clang/${LLVM_MAJOR}/include/|:N${LLVM_DIR}/lib/clang/${LLVM_MAJOR}/include/$}
  .endfor
  CLANG_DESC=   Build clang
  CLANG_CMAKE_ON=   -DCLANG_DEFAULT_OPENMP_RUNTIME=libomp
@@ -324,7 +324,7 @@ FREEBSD_BACKENDS=   ${_FREEBSD_BACKENDS}
  .if ${ARCH} == amd64
  _NATIVE_BACKENDS= X86
  .elif ${ARCH} == aarch64
-_NATIVE_BACKENDS=  AArch64
+_NATIVE_BACKENDS=  AArch64 ARM
  .elif ${ARCH:Marmv*}
  _NATIVE_BACKENDS= ARM
  .elif ${ARCH} == i386



I've set up devel/llvm15 to be based on that last change
as well.

===
Mark Millard
marklmi at yahoo.com

Re: pkg writing to /

[Daniel Braniss]

> On 6 Mar 2023, at 02:56, Kevin Oberman  wrote:
> 
> On Sat, Mar 4, 2023 at 11:37 PM Daniel Braniss  > wrote:
> Hi,
> how can I tell pkg not to write to /? in my case sometimes /
> is mounted ro, and so for example pkg update failed, or
> / - which is usually- kept as small as possible gets filled up, eg 
> by /.pkgtemp.compat.x/linux
> 
> thanks,
> danny
>  
> What command are you using? Normally pkg should not be writing to root unless 
> one of the files it does write to is on the same file system.

with a read-only root this failed:
pkg update

with a writable root the above works.

also, using portmaster …. (i don’t know which port, but suspect linux)
the root partition got filled up, and after some hunting i found 
du -hs /.pkgtemp.compat.7vhU2YxJLCDB/
243M/.pkgtemp.compat.7vhU2YxJLCDB/

> -- 
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com 
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: pkg writing to /

[Baptiste Daroussin]

On Sun, Mar 05, 2023 at 09:37:32AM +0200, Daniel Braniss wrote:
> Hi,
>   how can I tell pkg not to write to /? in my case sometimes /
> is mounted ro, and so for example pkg update failed, or
> / - which is usually- kept as small as possible gets filled up, eg 
> by /.pkgtemp.compat.x/linux
> 
> thanks,
>   danny
> 
> 
This is because you don't have a /compat on your / but you are trying to
install a package that installs files under /compat

Bapt

Re: How do I determine the ABI string used by pkg?

[Baptiste Daroussin]

On Wed, Mar 01, 2023 at 11:50:13PM -0800, Mel Pilgrim wrote:
> I need to determine the ABI string pkg uses on a given system, and need to
> do so when there are no pkgs installed.

pkg config ABI
pkg config ALTABI
> 
> I've read through libpkg/pkg_elf.c and I can see how it's reading ELF
> headers from well-known files.  That's all easy enough to replicate, but I'm
> a bit stuck on how it's determining the arch string for x86.

Why, what are you trying to do?
> 
> How/When does pkg decide to use FreeBSD:13:amd64 instead of
> FreeBSD:13:x86:64?  Can I safely assume one or the other?
> 
Internally pkg always and only uses freebsd:13:x86:64 internally and never 
FreeBSD:13:amd64.
the ALTABI allows fine grain matching of ABI and compatibility between arches.
ABI is a more user freindly way to read it.

Bapt

Re: pkg writing to /

[Daniel Braniss]

is this true also for ‘pky update’?

the /compat was a problem,
it was a symlink /usr/local/compat and for some reason the mkdir /compat/linux 
failed,
i did as root ‘mkdir /usr/local/compat/linux’, and linux installed ok.
danny


> On 6 Mar 2023, at 09:52, Baptiste Daroussin  wrote:
> 
> On Sun, Mar 05, 2023 at 09:37:32AM +0200, Daniel Braniss wrote:
>> Hi,
>>  how can I tell pkg not to write to /? in my case sometimes /
>> is mounted ro, and so for example pkg update failed, or
>> / - which is usually- kept as small as possible gets filled up, eg 
>> by /.pkgtemp.compat.x/linux
>> 
>> thanks,
>>  danny
>> 
>> 
> This is because you don't have a /compat on your / but you are trying to
> install a package that installs files under /compat
> 
> Bapt