Re: git for armv7

On May 3, 2023, at 10:49, Mark Millard <marklmi@yahoo.com> wrote:

> On May 3, 2023, at 10:29, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> bob prohaska <fbsd_at_www.zefox.net> 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.

Hmm:

# ldd `which git`
/usr/local/bin/git:
libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0xd8bcb4eb000)
libz.so.6 => /lib/libz.so.6 (0xd8bcc120000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0xd8bcd50c000)
libthr.so.3 => /lib/libthr.so.3 (0xd8bcc240000)
libc.so.7 => /lib/libc.so.7 (0xd8bcd8bb000)

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

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.

https://cgit.freebsd.org/ports/commit/?id=0f497b4088a2
should show the content of the:

devel/libunwind/files/patch-armv7

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
PORTSTREE METHOD TIMESTAMP           PATH
default   null   2021-04-18 02:05:47 /usr/ports


===
Mark Millard
marklmi at yahoo.com