Re: How seriously to take abi-check

[Jim Osborn <jimo at eskimo dot com>]

Thanks very much for the response, Benjamin.

On Mon, Mar 06, 2006 at 10:55:50AM -0600, Benjamin Kosnik wrote:
> Jim Osborn wrote:
> > I built gcc-3.4.5 with the --disable-nls option.  Configure and
> > "make bootstrap" made no complaints, but abi_check fails...
> >
> > Would that option break this test?
> 
> Perhaps. You don't specify your target, but since you care about
> this I'm assuming linux. 

Right.  I'll describe my environment at the end of this note.


> If you do a clean build, and then 'make check-abi' shows up
> failing, then your exports are messed up. 

Sorry to be such a novice, but what do you mean by "a clean build"?
In my case, after configuring the 3.4.5 tarball in its own build
directory with the options mentioned below, I did "make bootstrap"
then make check.  Does that qualify as clean?


> If you don't care about this, then you can ignore this failure. If
> you do care about this, then something is wrong. 

Well, I care.  But if I can't do anything about it, and never
experience any problems because of it, maybe I shouldn't care. :)
That's why I asked...  At the moment, I'm not writing my own C++
programs, just compiling downloaded tarballs.  But I would prefer
the results run correctly.


> Sometimes rebuilding/reconfiguring in the libstdc++ build directory
> messes up the list of current symbols though. 

So far I haven't done any rebuilding/reconfiguring, just various
retesting exercises: 'make check-abi' from the top gcc directory,
which fails for lack of a target; and from the 
i686-pc-linux-gnu/libstdc++-v3/ directory, with RUNTESTFLAGS="-v -v".

As I understand it, the test run grabs the current symbols each test,
but those symbols remain as they were when gcc/g++/libstdc++ was built.

I tried substituting the baseline_symbols.txt from the gcc-4.0.2
tarball, which is based on 3.4 binaries, as opposed to gcc-3.4.5
which is based on 3.2 binaries, according to the
libstdc++-v3/docs/html/abi.html file included in the respective
tarballs, but this test failed also, which doesn't surprise me.


> > Is there a way to get a "baseline" that corresponds to the config
> > options supplied to the build?  If not, is this test generally 
> > taken very seriously?  It seems to stop "make check" when it
> > fails, so I'm tempted to try to make it pass, but maybe I'm 
> > wasting my time. 
> 
> The baseline that is supported is linux, default configured.

Could you elaborate on what "default" means?  Does it mean no
config options at all?

I built gcc-3.4.5 with these configure options:
  --prefix=/usr/local/gcc-3.4.5
  --program-suffix=-3.4.5
  --disable-nls
  --disable-multilib
  --enable-threads=posix
  --with-cpu=pentium2
  --with-arch=pentium2
  --with-tune=pentium2
  --enable-version-specific-runtime-libs
  --enable-languages=c,c++

My environment is:
  glibc 2.2.4 (from an old SuSE 7.3 installation)
  linux kernel 2.4.23 (built using gcc 2.95.3)
  gcc 3.4.3
  autoconf 2.5.8
  automake 1.9.6
  libtool 1.5.20
  bison-2.1
  binutils 2.15.94.0.2.2
  libiconv 1.9.1
  gettext 0.13
  dejagnu 1.4.4

If "something is wrong" in my build of this compiler suite, I'd think
the only things I have control over are the configure options I give,
and my glibc.  I assume the bootstrapping process renders my current
gcc-3.4.3 a non-issue, and that the other libs I mention are irrelevant.

I wouldn't think, other than the --disable-nls, that my config
options would be non-default, but I certainly don't know, and that's
why I'm here asking.  If the abi test fails only because of those
config options, then I probably "don't care" about it. 

Perhaps SuSE did something funny with that glibc, and I do plan to
upgrade it eventually, but that's a fairly invasive upgrade, so I
keep putting it off. :)  If it's the source of these abi-check
failures, maybe I'll raise that priority. 

What else do I have control over?  Are my assumptions above correct?

Thanks again,

Jim