Re: git for armv7

From: Mark Millard <>
Date: Wed, 03 May 2023 19:01:42 UTC
On May 3, 2023, at 10:49, Mark Millard <> wrote:

> On May 3, 2023, at 10:29, Mark Millard <> wrote:
>> bob prohaska <> wrote on
>> Date: Wed, 03 May 2023 15:46:02 UTC :
>>> I have an armv7 Pi2 running -current and have somehow deleted my
>>> executable of git. The existing port fails with the libunwind breakage,
>>> I expected that re-enabling the master pkg site would allow me to re-fetch
>>> a runnable copy of git, but nothing is found for armv7. What the best way out
>>> of this pickle? 
>> main [so: 14] can run ports that are built for 13.* .
> See note below about that this may have been wrong
> for the context.
>> So pkg can be pointed at a 13.1-RELEASE quarterly
>> instead of latest and forced to get materials from
>> the quarterly, such as installing git from the
>> quarterly.
>> There is some chance that you might have to use
>> pkg for some of the quarterly activity via the
>> likes of:
>> env ABI=FreeBSD:13:aarch64 pkg . . .
>> It is still going to be a while before a armv7 git
>> shows up based on the fixed libunwind vintage. The
>> active build of main's latest, when I looked, still
>> predated the libunwind update for when it started.
>> The fix availability for main waits on the next
>> build of main's latest.
> There is some possibility that git will depend on an
> other things that would need to also come from
> quarterly as well. If so, the process is messier to
> get the full set in place.
> I've run main [so: 14] with all the ports being from
> 13.1-RELELASE main in the past. But I've never had
> the mix of ports from main and from 13.1-RELEASE's
> latest. My claims above may have been inappropriate
> to this context.


# ldd `which git`
/usr/local/bin/git: => /usr/local/lib/ (0xd8bcb4eb000) => /lib/ (0xd8bcc120000) => /usr/local/lib/ (0xd8bcd50c000) => /lib/ (0xd8bcc240000) => /lib/ (0xd8bcd8bb000)

indicates 2 /usr/local/lib/* libraries would be

Another option could be to establish an up-to-date
/usr/ports/ via another machine and then copying over
the material. (You might produce a different path
for this if it is to be temporary.) With a /usr/ports/
variant in place, you could build and install your way
out of the problem based on a fixed libunwind.

If you have poudriere using a local null mount of a
/usr/ports/ it would be possible to locally fix up
libunwind's port materials in the original /usr/port/
tree to match recent materials. Then you could build
and install your way out of the problem.
should show the content of the:


file that was added (but in a diff format).

Because my environment uses a null mount of a
/usr/ports/ that I control separately from poudriere,
but have poudriere use, that last is what I would do
in my context. For reference, for my context:

# poudriere ports -l
default   null   2021-04-18 02:05:47 /usr/ports

Mark Millard
marklmi at