Re: Bootstrapping pkgsrc with a compiler

[Greg Troxel <gdt%lexort.com@localhost>]

Martin Husemann <martin%duskware.de@localhost> writes:

> I have a bit of trouble with generic statemens like this.

The issue is:

  there is no guarantee of ABI stability in gcc/c++, in that

    build libA with gcc X

    build programB that links with libA with gcc Y (and implicitly,
    linkt with Y's libstdc++)

  is not guaranteeed by the gcc people to work.  Joerg has said
  repeatedly that this is unsound.

My impression is that as long is the link is done with the max version
of all the libs and prgoram, and nothing before gcc 4.8 is used, it
tends to work.

So I am saying

  we cannot rely on things that are not guaranteed

and you seem to be saying

  we can rely on things unless they are documented to break

but I think that's probably not what you meant and a bit unfair.


> Maybe it helps if we compile a list of actual ABI breakage points and
> attribute them properly? Like the switch in string handling in gcc's
> libstdc++ on NetBSD (and I already forgot when this happened - from
> netbsd-8 to netbsd-9?) But this should not matter for any other
> compiler's libstdc++ nor for gcc on any other platform.

Listing what actual ABI issues exist today is useful.  But it does not
refute the statement that there are no stability specifications.  And
this is pkgsrc, with many compilers and many platforms.


(My impression is that the C ABI is actually specified, so this is not a
problem for C.  But then again, for C you can almost always use the
compiler you have.)


and what are we trying to "help"?  Are you saying that pkgsrc having a
two-stage bootstrap for using another compiler is bad, and that the risk
of ABI issues is so small that moving away from theoretical soundness is
outweighted by [some good thing that happens by not doing two-stage
bootstrap]?