unnecessary --enable-plugin tests

Jack Howarth howarth@bromo.med.uc.edu
Thu Apr 22 16:04:00 GMT 2010


On Thu, Apr 22, 2010 at 05:12:19PM +0200, Richard Guenther wrote:
> On Thu, Apr 22, 2010 at 5:08 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> > On Thu, Apr 22, 2010 at 07:38:04AM -0700, Ian Lance Taylor wrote:
> >> Jack Howarth <howarth@bromo.med.uc.edu> writes:
> >>
> >> >    Looking at the results of the tests executed
> >> > by plugin.exp on x86_64 Fedora 10, I don't see
> >> > any evidence that -rdynamic is ever used.
> >>
> >> On GNU/Linux, in order to use plugins, it's necessary to use -rdynamic
> >> when linking cc1.  Otherwise plugins will not be able to access many
> >> functions and variables in cc1.
> >>
> >> Darwin has a somewhat different model; I don't know if anything
> >> similar is required there.
> >>
> >> Ian
> >
> > Ian,
> >   Since the proposed patch on darwin (using 'nm -g') reports
> > to configure that -rdynamic is unnecessary on darwin and the
> > resulting gcc build generates code via dragon-egg, I believe
> > we can infer that this isn't an issue on darwin. So I guess
> > my current patch should be best...
> >
> > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01345.html
> >
> > Of course, it should be adjusted later for Solaris and
> > Irix once they sort out which set of devtools and utilities
> > will be the baseline requirement of compiling plugin support
> > (since the system compilers may not provide -rdynamic and
> > objdump may not be present).
> 
> If plugins work on Solaris and Irix currently then we shouldn't
> regress for them.

Richard,
   Okay, I've posted a fifth revision of this patch that reverts
to using "$gcc_cv_objdump -T" on non-darwin hosts as before. I
also verified objdump from binutils 2.20.1 on powerpc-apple-darwin9
that darwin doesn't require -rdynamic to export symbols...

echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
gcc conftest.c -o conftest
objdump -T conftest | grep foobar
00000f69 g       0f SECT   01 0000 .text _foobar

                Jack
> 
> Richard.
> 
> >          Jack
> >
> >
> >



More information about the Gcc mailing list