problems building a release
Mark Millard
marklmi at yahoo.com
Sat Mar 13 09:40:24 UTC 2021
On 2021-Mar-13, at 00:11, Don Lewis <truckman at FreeBSD.org> wrote:
> On 10 Mar, Mark Millard wrote:
>> On 2021-Mar-10, at 15:00, Don Lewis <truckman at FreeBSD.org> wrote:
>>
>>> I'm trying to build a customized 13.0 i386 release on a amd64 host
>>> running FreeBSD 14.0-CURRENT #89 n245058-1ca8842f3ad9. The source tree
>>> is branch releng/13.0 from last night. The release build gets most of
>>> the way through, but fails with:
>>>
>>> ===> usr.bin/svn/lib/libsvn_wc (installconfig)
>>> --- installconfig_subdir_usr.sbin ---
>>> --- installconfig_subdir_usr.sbin/pkg ---
>>> --- installdirs-CONFSDIR ---
>>> --- _CONFSINS_FreeBSD.conf.quarterly ---
>>> --- installdirs-CONFSDIR ---
>>> installing DIRS CONFSDIR
>>> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratch/etc/pkg
>>> --- _CONFSINS_FreeBSD.conf.quarterly ---
>>> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf
>>> Shared object "libedit.so.8" not found, required by "sh"
>>>
>>> /scratch/bin/sh seems to work, though it is using the host library:
>>> # ldd /scratch/bin/sh
>>> /scratch/bin/sh:
>>> libedit.so.8 => /usr/lib32/libedit.so.8 (0x20463000)
>>> libc.so.7 => /usr/lib32/libc.so.7 (0x20495000)
>>> libncursesw.so.9 => /usr/lib32/libncursesw.so.9 (0x20683000)
>>> # /scratch/bin/sh
>>> #
>>>
>>> The library is present in /scratch/lib:
>>> # file /scratch/lib/libedit.so.8
>>> /scratch/lib/libedit.so.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 (1300139), stripped
>>>
>>> Unfortunately the build isn't verbose enough to give me any hints about
>>> where the problem might be. I've been able to build FreeBSD 11.x and
>>> 12.x releases this way, but no luck so far with 13.
>>>
>>> Update: I am able to build an amd64 release, so the problem has
>>> something to do with crossbuilds. There are some other problems that
>>> crop up, though.
>>>
>>>
>>> ===> usr.bin/svn/lib/libsvn_wc (installconfig)
>>> --- installconfig_subdir_usr.sbin ---
>>> --- installconfig_subdir_usr.sbin/pkg ---
>>> --- installdirs-CONFSDIR ---
>>> --- _CONFSINS_FreeBSD.conf.quarterly ---
>>> --- installdirs-CONFSDIR ---
>>> installing DIRS CONFSDIR
>>> install -N /scratch/usr/src/etc -d -m 0755 -o root -g wheel /scratch/etc/pkg
>>> --- _CONFSINS_FreeBSD.conf.quarterly ---
>>> install -N /scratch/usr/src/etc -C -o root -g wheel -m 644 /scratch/usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly /scratch/etc/pkg/FreeBSD.conf
>>> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/perl5/5.20/mach/CORE
>>> 32-bit compatibility ldconfig path: /usr/lib32
>>> pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
>>> Updating FreeBSD repository catalogue...
>>> Fetching meta.txz: 100% 916 B 0.9kB/s 00:01
>>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2
>>> repository FreeBSD has no meta file, using default settings
>>> Fetching packagesite.txz: 100% 6 MiB 1.6MB/s 00:04
>>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2
>>> Unable to open created repository FreeBSD
>>> Unable to update repository FreeBSD
>>> All repositories are up-to-date.
>>> pkg: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2
>>> pkg: Repository FreeBSD cannot be opened. 'pkg update' required
>>> Updating database digests format: 100%
>>> pkg: No packages available to install matching 'devel/git' have been found in the repositories
>>
>>
>> To my knowledge FreeBSD does not support 14 directly
>> building 13 or before: self hosted and sufficiently
>> recent older building newer only, as far as direct
>> builds go.
>
> That doesn't seem to be the problem that I'm running into. I run into a
> similar problem when trying to build a 14-CURRENT release. The cause of
> the problem seems to be that I'm specifying TARGET=i386 and TARGET_ARCH=i386
> in both release.conf, and the make.conf that release.conf points to.
> With 14-CURRENT the failure mode is that something can't find ld-elf.so
> and aborts. That happens a number of times during the release build,
> but this time the release build appears to run to completion. If I
> remove the make.conf settings, then the error goes away. The reason
> that I did this in the first place was so I could set TARGET_CPUTYPE.
> This setting appears to be ignored in release.conf. If I set it in
> make.conf without setting TARGET=i386 and TARGET_ARCH=i386, then I get a
> compiler error because the CPUTYPE is not valid on amd64. Basically,
> the difference is that with the settings in both places, I get an i386
> chroot under /scratch and with the settings different, the chroot is
> amd64. I thing the failure is being caused when something tries to run
> an amd64 executable in under the i386 chroot. Verbosity is too low to
> see what it is.
>
> Another complication is that I want to maintain the target system with
> freebsd-update, so I need to package up my customized make.conf and
> src.conf into the release so they get used by the update builder. It
> should be easy to tweak the release script to do this, but it gets
> complicated if the the make.conf files have different TARGET settings.
>
You are definitely working outside my direct
experience. But I'll note that
release/release.conf.sample and the man page
have all of the following, not that I
understand the various implications of use:
## Set to override the default target architecture.
#TARGET="amd64"
#TARGET_ARCH="amd64"
#KERNEL="GENERIC"
## Multiple kernels may be set.
#KERNEL="GENERIC XENHVM"
. . .
## Set to pass additional flags to make(1) for the build chroot setup, such
## as TARGET/TARGET_ARCH.
#CHROOT_MAKEENV=
Also described via:
CHROOT_MAKEENV Additional make(1) arguments to pass through, which
directly affect the tuning of the build chroot.
TARGET and TARGET_ARCH are also listed as controllable
via the ENVIRONMENT :
TARGET The target hardware platform. This is analogous to the
“uname -m” output. This is necessary to cross-build
some target architectures. For example, cross-building
for ARM64 machines requires TARGET_ARCH=aarch64 and
TARGET=arm64. If not set, TARGET defaults to the
current hardware platform.
TARGET_ARCH The target machine processor architecture. This is
analogous to the “uname -p” output. Set this to cross-
build for a different architecture. If not set,
TARGET_ARCH defaults to the current machine
architecture, unless TARGET is also set, in which case
it defaults to the appropriate value for that platform.
Typically, one only needs to set TARGET.
A possibility would seem to be use of:
## Set to the hardware platform of the target userland. This value
## is passed to make(1) to set the TARGET (value of uname -m) to cross
## build.
#EMBEDDED_TARGET=
## Set to the machine processor architecture of the target userland.
## This value is passed to make(1) to set the TARGET_ARCH (value of uname -p)
## to cross build.
#EMBEDDED_TARGET_ARCH=
May be EMBEDDEDBUILD= with an empty or nonexistent EMBEDDEDPORTS
might happen to do somethings useful for your context? (Implication
of WITH_DVD being unset when EMBEDDEDBUILD= is in use. Implicit
EMBEDDEDPORTS such as devel/subversion ?)
A different direction is to have release use a pre-existing build
(separately built beforehand). As I vaguely remember, this involved:
## Set to skip the chroot environment buildworld/installworld/distribution
## step if it is expected the build environment will exist via alternate
## means.
#CHROOTBUILD_SKIP=
Also described via:
CHROOTBUILD_SKIP
If defined, the buildworld, installworld, and
distribution stages of the chroot(8) build environment
setup are skipped. This is intended solely for cases
where the chroot(8) userland are provided by alternate
means.
There are also:
## Redefine environment variables here to override prototypes
## defined in release.sh.
#load_chroot_env() { }
#load_target_env() { }
#buildenv_setup() { }
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-hackers
mailing list