lib32 not installed - but required when update

[vermaden]

Hi.

1. I installed FreeBSD 15.0-BETA1 with packages from ISO with only base selected. No lib32 installed.

2. Then modified 'url' in /usr/local/etc/pkg/repos/FreeBSD-base.conf file:

- url: "pkg+https://pkg.freebsd.org/${ABI}/base_latest",
+ url: "pkg+https://pkg.freebsd.org/${ABI}/base_release_${VERSION_MINOR}",

3. Then wanted to update vi package:

root@pkgbase:~ # pkg install FreeBSD-vi
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        FreeBSD-clibs-lib32: 15.0.b1.20251012072228 [FreeBSD-base]

Installed packages to be UPGRADED:
        FreeBSD-vi: 15.0.b1.20251011075131 -> 15.0.b1.20251012072228 [FreeBSD-base]

Number of packages to be installed: 1
Number of packages to be upgraded: 1

The process will require 4 MiB more space.
2 MiB to be downloaded.

Proceed with this action? [y/N]: 

Why lib32 dependency is pulled in/required when I do not have anything lib32 related installed?

Regards, vermaden

[markmi]

FYI: FreeBSD-clang depends on both FreeBSD-clibs and FreeBSD-clibs-lib32 :

# pkg info -d FreeBSD-clang
FreeBSD-clang-16.snap20251014184832:
	FreeBSD-lld-16.snap20250930012546
	FreeBSD-libcompiler_rt-dev-16.snap20250923153156
	FreeBSD-clibs-16.snap20251014203606 (libc++.so.1)
	FreeBSD-clibs-16.snap20251014203606 (libc.so.7)
	FreeBSD-clibs-lib32-16.snap20251014184832 (libc.so.7:32)
	FreeBSD-clibs-16.snap20251014203606 (libcxxrt.so.1)
	FreeBSD-libexecinfo-16.snap20251003201239 (libexecinfo.so.1)
	FreeBSD-clibs-16.snap20251014203606 (libgcc_s.so.1)
	FreeBSD-clibs-lib32-16.snap20251014184832 (libgcc_s.so.1:32)
	FreeBSD-clibs-16.snap20251014203606 (libm.so.5)
	FreeBSD-ncurses-16.snap20251003201239 (libncursesw.so.9)
	FreeBSD-runtime-16.snap20251014184832 (libprivatezstd.so.5)
	FreeBSD-clibs-16.snap20251014203606 (libthr.so.3)
	FreeBSD-ncurses-16.snap20251003201239 (libtinfow.so.9)
	FreeBSD-runtime-16.snap20251014184832 (libz.so.6)

The lib32 libc.so.7:32 and libgcc_s.so.1:32 looks to be because of providing libclang_rt.asan-i386.so:32 :

# pkg info -b FreeBSD-clang
FreeBSD-clang-16.snap20251014184832:
	libclang_rt.asan-i386.so:32
	libclang_rt.asan-x86_64.so
	libprivateclang.so.19
	libprivatellvm.so.19

# ldd -a /usr/lib/clang/19/lib/freebsd/libclang_rt.asan-i386.so
/usr/lib/clang/19/lib/freebsd/libclang_rt.asan-i386.so:
	libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0x209d1000)
	libc.so.7 => /usr/lib32/libc.so.7 (0x209f0000)
/usr/lib32/libgcc_s.so.1:
	libc.so.7 => /usr/lib32/libc.so.7 (0x209f0000)
/usr/lib32/libc.so.7:
	libsys.so.7 => /usr/lib32/libsys.so.7 (0x20bef000)
[preloaded]
	[vdso] (0xffffe780)

[markmi]

Also, both FreeBSD-set-base* do (indirectly) include references to FreeBSD-clibs-lib32 :

# pkg info -r FreeBSD-set-devel
FreeBSD-set-devel-16.snap20251008042735:
	FreeBSD-set-base-jail-16.snap20251008042735
	FreeBSD-set-base-16.snap20251008042735

# pkg info -d FreeBSD-set-devel | grep clang
	FreeBSD-clang-dev-16.snap20251014184832
	FreeBSD-clang-16.snap20251014184832

# pkg info -d FreeBSD-clang | grep lib32
	FreeBSD-clibs-lib32-16.snap20251014184832 (libc.so.7:32)
	FreeBSD-clibs-lib32-16.snap20251014184832 (libgcc_s.so.1:32)

[grahamperrin]

https://github.com/freebsd/pkg/issues/2544#issue-3530054292

… to update vi package:

root@pkgbase:~ # pkg install FreeBSD-vi …

Seeing pkg-install(8), I assume that you had previously forced deletion of FreeBSD-vi.

… installed FreeBSD 15.0-BETA1 with packages from ISO …

The result would have been STABLE – not BETA1. I should expect any number of differences between the two.

Also, https://lists.freebsd.org/archives/freebsd-stable/2025-October/003389.html (2025-10-12) @cperciva wrote, in response to Mark's email about the change of url for FreeBSD-base:

… The rolling builds on pkg.freebsd.org are useful of course but they're not quite the same thing -- they'll give you "whatever releng/15.0 is today" rather than specifically 15.0-BETA1. …

Et cetera.

Is this truly a pkg issue?

---

Defocusing from vi:

• simply switching from STABLE to BETA2 involves addition of FreeBSD-clibs-lib32: 15.0.b2.20251023042929.

That is, STABLE as a result of installation from FreeBSD-15.0-BETA2-amd64-dvd1.iso not using offline packages.

After pkg.conf(5)-related corrections:

pkg issue 2544 BETA2 example.txt

[cperciva]

Is this truly a pkg issue?

Yes, it's the same issue as https://github.com/freebsd/pkg/issues/2520 . Basically pkg is looking at only the basename of libraries so it doesn't realize that /usr/lib/foo.so is a different library from /usr/lib32/foo.so. @ifreund is looking into fixing this.

[grahamperrin]

Thanks @cperciva, and is 2520 the underlying cause of 2414?

• #2414
• #2520

[cperciva]

I have no idea what's going on in #2414. Might be related? Or it might be a different thing bug; I would have to look at the names of .so files to be sure (and I don't want to do that right now, I've got too many other issues to chase).

[llfw]

Basically pkg is looking at only the basename of libraries so it doesn't realize that /usr/lib/foo.so is a different library from /usr/lib32/foo.so.

this hasn't been true since pkg learned a long time ago to differentiate libfoo.so from libfoo.so:32. before that, installing pkgbase packages would randomly pull in 32- or 64-bit dependencies depending on which it found first, which no longer happens.

clearly something is going wrong in this case, but it's not as simple as pkg not being able to tell 32- and 64-bit libraries apart.

[ifreund]

Yes, it's the same issue as #2520 . Basically pkg is looking at only the basename of libraries so it doesn't realize that /usr/lib/foo.so is a different library from /usr/lib32/foo.so. @ifreund is looking into fixing this.

This is not entirely correct, while pkg does look at the basename of shared libraries rather than their location on the filesystem, pkg also looks at the architecture of shared libraries and is therefore able to distinguish between /usr/lib/foo.so and /usr/lib32/foo.so assuming the former is an x86_64 shared library and the later is an i386 shared library. I think this is a separate issue from https://github.com/freebsd/pkg/issues/2520.

After looking at this issue in more depth, it's not clear to me that pkg is doing something wrong here. It is correct that FreeBSD-clang15 includes a 32-bit library (/usr/lib/clang/19/lib/freebsd/libclang_rt.asan-i386.so) which is dynamically linked against the shared libraries provided by FreeBSD-clibs-lib32.

However, just because pkg is technically correct doesn't mean that it's good for FreeBSD-clang15 to depend on FreeBSD-clibs-lib32. I see two ways this dependency could be eliminated:

1. The problematic file (/usr/lib/clang/19/lib/freebsd/libclang_rt.asan-i386.so) could be split off into a new FreeBSD-clang-rt-lib32 package.
2. The build system could tell pkg to ignore shlibs required by the problematic file using SHLIB_REQUIRE_IGNORE_GLOB.

I think I like option 2. a bit more. Option 1. makes it possible to have clang installed without libclang_rt.asan-i386.so present on the system, which could lead to confusing compilation errors.

[bapt]

I agree 200% with @ifreund here.

[cperciva]

Yeah ok we might be looking at many different issues. I was hoping they were all the same.

The issue I tripped over (ebsnvme-id pulling in random garbage) is absolutely a bug though, it doesn't use any 32-bit libraries and the false dependencies pkg decides to install for it get removed again via 'pkg autoremove'. There's no logical scenario where 'pkg install' should install something which 'pkg autoremove' immediately uninstalls.