tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: libstdc++.so and mysterious build errors



Havard Eidnes <he%NetBSD.org@localhost> writes:

> 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.

  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.

> 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]

  2) switch to clang

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

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

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index