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

[Matt Austern]

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.)

			--Matt