Re: Regressions in objc/execute after latest ObjC patch

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Wed, 10 Oct 2001 12:00:17 -0700
> Cc: Stan Shebs <shebs@apple.com>
> From: Ziemowit Laski <zlaski@apple.com>
> 
> Ok, I did get a chance to test this out under RH Linux 7.1.
> Indeed, the objc/execute testsuite has the failures you
> indicate when run against top-of-trunk, whereas the 3.0.1 branch
> does not.  The failure manifests itself as follows, when you compile and 
> then
> attempt to run a test case:
> 
> ./a.out: error while loading shared libraries: libgcc_s.so.1: cannot load
> shared object file: No such file or directory
> 
> Per Stan's suggestion, I tried rebuilding the compiler with 
> --disable-shared.
> When I did this, the above message was replaced with a segmentation 
> fault. :)
> 
> Since my patch did not have anything to do with shared library 
> searching/loading
> (indeed, the ObjC patch did not introduce any functional changes at 
> all!), I
> next tried rolling back the 3 files making up the patch:
> 
>    gcc/c-parse.in
>    gcc/objc/objc-act.c
>    gcc/objc/objc-act.h
> 
> and rebuilding the compiler.  THE FAILURES REMAIN.  Hence, I've 
> tentatively
> concluded that the latest ObjC patch is NOT responsible for the observed
> regressions in objc/execute.  Instead, I suspect that some other change,
> checked in at about the same time as the ObjC patch, may be responsible.
> Has anyone touched anything related to libgcc or shared lib usage in the
> last week or so?

I think you're seeing some other problem than the one the regression
tester sees.  Here's an example of the objc.log file output for a
typical test case, this one for powerpc-eabisim:

Executing on host: /maat/heart/tbox/powerpc-eabisim/build/gcc/xgcc
-B/maat/heart/tbox/powerpc-eabisim/build/gcc/
/maat/heart/tbox/cvs-gcc/gcc/gcc/testsuite/objc/execute/IMP.m  -w  -O
-I/maat/heart/tbox/cvs-gcc/gcc/gcc/testsuite/../../libobjc
-L/maat/heart/tbox/powerpc-eabisim/build/powerpc-eabisim/libobjc/.libs
-msim   -lobjc  -lm   -o
/maat/heart/tbox/powerpc-eabisim/build/gcc/testsuite/IMP.x    (timeout
= 300)
spawn /maat/heart/tbox/powerpc-eabisim/build/gcc/xgcc
-B/maat/heart/tbox/powerpc-eabisim/build/gcc/
/maat/heart/tbox/cvs-gcc/gcc/gcc/testsuite/objc/execute/IMP.m -w -O
-I/maat/heart/tbox/cvs-gcc/gcc/gcc/testsuite/../../libobjc
-L/maat/heart/tbox/powerpc-eabisim/build/powerpc-eabisim/libobjc/.libs
-msim -lobjc -lm -o
/maat/heart/tbox/powerpc-eabisim/build/gcc/testsuite/IMP.x
PASS: objc/execute/IMP.m compilation,  -O
spawn powerpc-eabisim-run
/maat/heart/tbox/powerpc-eabisim/build/gcc/testsuite/IMP.x
/maat/heart/tbox/powerpc-eabisim/build/gcc/testsuite/IMP.x: Caught
signal 11 at address 0x10001b28

on linux, it's even simpler:

PASS: objc/execute/IMP.m compilation,  -O
spawn [open ...]
FAIL: objc/execute/IMP.m execution,  -O 

The tester doesn't use any special --enable or --disable flags at all,
it's just

$SOURCE/configure --prefix=$PREFIX --target=$H_TARGET || exit 1
if [ $H_HOST = $H_TARGET ] ; then
  make bootstrap || exit 1
else
  make || exit 1
fi

-- 
- Geoffrey Keating <geoffk@geoffk.org>