Re: libstdc++.so and mysterious build errors

[Havard Eidnes <he%NetBSD.org@localhost>]

>> I can of course do as indicated above and remove libstdc++.so
>> version 6, 7 and 8 from /usr/lib, remove any binary packages
>> which lists any of those libstdc++.so's as REQUIRED (yes, there
>> were some), and re-start the entire bulk build.
>
> I would say there are two separable problems:
>
>   programs built with base system compilers that existed in previous
>   netbsd versions.   If a library, this is a misconfiguration.

Not entirely sure what you mean here, but...  I removed the
libstdc++.so versions 6, 7 and 8 from the chroot's /usr/lib.  I
checked and didn't find any executables in the chroot's standard
bin directories which depended on any of them.

>   what happens with a fresh build of all of pkgsrc on a given netbsd
>   version
>
> and you might as well patrol for /usr/lib/libstdc++.so.N for N being
> old, and rebuild those, to take the first issue off the table.

Yes, and I already did that via 

for all pkgfile...
  pkg_info -B $pkgfile | egrep "REQUIRE.*libstdc\+\+.so.[678]'

and found a few which are now moved out of the packages/All
directory, and I aborted the current build and started a new, and
those packages will need to be rebuilt.  These were the ones:

-rw-r--r--  2 root  wheel     650071 Aug  9 10:32 tnt-mmtl-1.2.2nb14.tgz
-rw-r--r--  2 root  wheel      58750 Sep  3 21:53 x11-links-1.35.tgz
-rw-r--r--  1 root  wheel  147281971 Sep 10 17:56 gcc10-10.4.0.tgz
-rw-r--r--  1 root  wheel  130756768 Oct 22 20:39 gcc9-9.3.0nb9.tgz
-rw-r--r--  1 root  wheel  127427349 Oct 23 16:26 gcc8-8.4.0nb7.tgz
-rw-r--r--  1 root  wheel  105081703 Oct 24 08:03 gcc7-7.5.0nb6.tgz
-rw-r--r--  1 root  wheel   95519986 Oct 24 22:01 gcc6-6.5.0nb8.tgz
-rw-r--r--  1 root  wheel  160124398 Oct 25 22:50 gcc12-12.2.0.tgz

and as you see, many of them were built recently-ish. (Hmm, why
do two of them have > 1 links?  Need to look into that.)

>> I am however not entirely convinced that will sort out this
>> problem properly either.  The reason is that e.g. in the main R
>> package, ${PREFIX}/lib/R/library/grDevices/libs/cairo.so gets
>> installed, and via a dynamic dependency via libpangocairo-1.0.so,
>> libpangoft2-1.0.so, libharfbuzz.so and then libgraphite2.so, the
>> latter has a dynamic libstdcc++.so.9 dependency which is found in
>> /usr/lib, since libgraphite2.so is most probably built with the
>> in-tree c++ compiler.
>>
>> Once I've removed /usr/lib/libstdc++.so.7, whenever the R module
>> mentioned earlier is loaded, you can end up with two different major
>> versions of libstdc++.so dynamically loaded due to the divergent major
>> shared library version numbering scheme between pkgsrc gcc and in-tree
>> gcc.  That sounds to me like a recipe for disaster, but what do I know
>> -- is some trick used so that this isn't really a problem?  Or will
>> symbols now without warning or error resolve to just one of them?  Or
>> will you get a dynamic linker error message when the latter is
>> attempted loaded?
>
> This is indeed a mess and IMHO the only sane paths are one of
>
>   1) build new gcc from pkgsrc eg gcc10
>
>   set pkgsrc USE_GCC=10
>
>     [pkg_admin set rebuild=YES *
>     pkg_rolling-replace]
>   or
>     [do gcc before building anything]

This is a bulk build, so "additional manual procedures" are
probably out of the question.  And this gets complicated pretty
quickly.

BTW, switching to pkgsrc gcc10 doesn't guarantee success, because
... you might still end up with using libstdc++.so.9 from the
base system depending on the specified library search path (and
default library search path).

You'll probably not get a warning that the given VERSION
requirement isn't met at linking time, though, similar to the one
I quoted earlier in this thread, as base system libstdc++.so.9 is
most probably comparable feature-wise to the pkgsrc gcc10's
libstdc++.so.7.

>   2) switch to clang

Well, that's heavier lifting than I was contemplating in this
round.  Not entirely sure how one would go about actually doing
that, and what the practical effects of that would be for users
of the resulting binary packages.  And the pkg build success rate
may plummet as a result -- have not looked too closely at the
clang pkgsrc build reports.

"Too many unknowns for me at the moment."

>   3) build a gcc in a second prefix and configure pkgsrc to use that

Won't this also fall victim to the same as #1 above?

>   4) switch to current and hope that gcc is good enough

If I understand correctly, #4 won't resolve the issue -- the
build I'm struggling with is on a to-be-10.0 system.  The reason
is that the R packages use gfortran, and that's not part of the
base system, so forces the use of pkgsrc gcc10, also for C and
C++.  And pkgsrc gcc10 has a different major versioning scheme
for libstdc++ than the base system gcc (which is also version
10), so we might end up with both libstdc++.so.9 from the base
system and libstdc++.so.7 from pkgsrc gcc10 in the same
executable.  Not sure that will work out so well(?)


I'm sorry I don't have a good suggestion for how to actually go
about fixing this problem properly...


Regards,

- Håvard