This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Software Convention Proposal


Richard,

Sorry for the long latency.  I'm a little confused by your example,
and haven't quite been able to find the right man page to answer my
question.

If I understand what you are saying about building a shared library,
then without -fpic the following global symbol visibility rules apply:
1) if a symbol is defined, it is treated as protected (and made gprel if
short)
2) if a symbol is extern (or, I presume, common), it is treated as default
The error from the linker then comes from having an extern reference
to a defined symbol in another .o.  Is this what you were saying?
Adding -fvisibility=protected then alters this to minshared by
turning the extern symbol to protected (and hence gprel).

Thanks for the clarification.

Best regards,

David
  
-----Original Message-----
From: Richard Henderson [mailto:rth@redhat.com]
Sent: Wednesday, August 28, 2002 9:54 AM
To: Kirkegaard, Knud J
Cc: 'gcc@gcc.gnu.org'; Sehr, David C; Saxena, Sunil; 'cary@cup.hp.com';
Winalski, Paul
Subject: Re: Software Convention Proposal


On Fri, Aug 23, 2002 at 02:47:04PM -0700, Kirkegaard, Knud J wrote:
> It is not exactly the same as -fno-pic since the default is still PIC...

This is not actually correct.  For gcc, the presence or abscense of
-fpic on the command line *does* change the symbol resoution rules
used inside the compiler.  It is already the case that shared libraries
must be compiled with -fpic or you'll get link errors of the form

  file.o: @gprel relocation against dynamic symbol foo

Thus, from my point of view, your -fminshared is exactly the same as
-fvisibility=protected and without -fpic.



r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]