Compiling glibc-2.3.2 (-2.3.3?) snapshot 20031115 with gcc-3.4 snapshot 20031119

Daniel Jacobowitz drow@mvista.com
Tue Dec 2 20:21:00 GMT 2003


On Tue, Dec 02, 2003 at 12:15:13PM -0800, Matt Austern wrote:
> On Dec 2, 2003, at 7:37 AM, Jakub Jelinek wrote:
> 
> >On Tue, Dec 02, 2003 at 09:35:51AM -0800, Matt Austern wrote:
> >>As you might have noticed from following the discussion on the
> >>gcc list, the main reason I haven't fixed this yet is that we haven't
> >>yet reached an agreement about what the semantics of the
> >>visibility attribute should be when you've got multiple declarations
> >>of the same symbol.
> >>
> >>What assumptions does the glibc source make about this, and how
> >>tightly wedded are you to those assumptions?
> >
> >glibc assumes that if there is a decl without visibility attribute
> >and decl with visibility attribute, that the visibility specified
> >in the visibility attribute is used.
> >
> >Say:
> >int foo (void) __attribute__((visibility ("hidden")));
> >int bar (void);
> >...
> >int foo (void) { return 1; }
> >int __attribute__((visibility ("hidden"))) bar (void) { return 2; }
> >
> >then both foo and bar are hidden.
> 
> OK!  The next question, then: do you assume that explicitly
> providing a default visibility, and not providing a visibility at
> all, are different?  That is, would you expect
>    int foo (void) __attribute__((visibility ("hidden")));
>    int foo (void) __attribute__((visibility ("default"))) { return 137; 
> }
> to behave differently than
>    int foo (void) __attribute__((visibility ("hidden")));
>    int foo (void) { return 137; }?
> 
> (I hope the answer is no, and that default is just default.  I know
> how to make the compiler treat the two kinds of default differently,
> but it'll be a little more expensive and convoluted.)

But... wouldn't this be necessary if there was a switch to change the
"default" visibility of compiler-generated symbols?  Something which
has been both requested and proposed in the past.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



More information about the Gcc mailing list