Re: Trying to build exiv2-0.82.0nb3 on aarch64

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

On Wed, 6 Dec 2023 at 08:00:41 -0000 (UTC), Michael van Elst wrote:
> widupmm%proton.me@localhost (Matthew Widup) writes:
>
> > I installed NetBSD-9.3 and pkgsrc 2023Q3, and get the same results.
> > I found that libstdc++.so.7 is in /usr/pkg/GCC10/lib/=20
> > GCC10 is required by exiv2
> > It also exists on another machine (amd64) which builds exiv2-0.82.0nb3 
> > also=
> > from pkgsrc 2023Q3 without a hitch.  It may warn about libstdc++.so.7, 
> > I'm=
> > not sure.
> > Is libstdc++.so.7 even the real problem?  (I ask because I don't know) 
> >  Tha=
> > t warning comes quite some time before compilation stops.  (about ten 
> > minut=
> > es on my PBP yesterday)
>
>
>
> exiv2 didn't build for netbsd-9/aarch64:
>
> [100%] Linking CXX executable ../bin/exiv2
> /usr/bin/ld: warning: libstdc++.so.9, needed by 
> /usr/pkg/lib/libINIReader.so.0, may conflict with libstdc++.so.7
> /usr/bin/ld: ../bin/exiv2: hidden symbol `__aarch64_ldadd4_acq_rel' in 
> /usr/pkg/gcc10/lib/gcc/aarch64--netbsd/10.5.0/libgcc.a(ldadd_4_4.o) is 
> referenced by DSO
> /usr/bin/ld: final link failed: bad value
> collect2: error: ld returned 1 exit status
> --- bin/exiv2 ---
> *** [bin/exiv2] Error code 1
>
>
> netbsd-9 uses libstdc++.so.9, but you can see that pkgsrc tries to 
> build
> exiv2 using the pkgsrc gcc10 package. And that uses incompatible 
> library
> versions:
>
> lib/libstdc++.a
> lib/libstdc++.la
> lib/libstdc++.so
> lib/libstdc++.so.7
> lib/libstdc++.so.7.28
> lib/libstdc++.so.7.28-gdb.py
> lib/libstdc++fs.a
> lib/libstdc++fs.la
> share/gcc-10.5.0/python/libstdcxx
>
> I would consider the gcc10 package broken.
>
>
> netbsd-10 builds exiv2 with the native compiler, so there is no such
> conflict.

There are a couple of different things to consider here. The original
report was against NetBSD 10.99.2, which natively provides GCC 10, yet
the example failure given was using GCC 10 from pkgsrc. I don't follow
why that would be happening (it shouldn't by default). As Michael
hints, simply using the native GCC on NetBSD >= 9.99.82 should "just
work" here, there's no reason to pull in GCC from pkgsrc. (If that is
happening because of pkgsrc infrastructure, that's a bug, IMO, but it
doesn't happen by default. Is that being forced by user settings? Or
is the userland in that example actually older than 10.99.2? Or
something else?)

With the use of a compiler from pkgsrc plus a dependency (inih) that
would normally use the base GCC (even on 9.3), yes, you'll also have
the issue that there are two libstdc++ libraries in the mix.

I think probably anyone who wants better aarch64 support should stick
with NetBSD 10 at this point. (Though I realize the downgrade to 9.3
was for testing purposes.) So the simple answer would be: go back to
10 (or 10.99.2 to test), don't use the GCC from pkgsrc for anything,
and it should "just work".

If you really want to tinker with either 9.3 or the exact state of
pkgsrc that seems to exist with the original 10.99.2 environment that
was reported, the hack to try would be to copy the file "hacks.mk"
from audio/openal-soft to graphics/exiv2 and recompile. That should
also work around the issue. (Though, again, I don't recommend that as
the best approach.)

Regards,

Dave