Add hidden visibility to internal function prototypes

  On 08/21/2017 11:15 PM, Joseph Myers wrote:
> On Mon, 21 Aug 2017, Florian Weimer wrote:
> 
>>> The test links with libc.so, but it uses various GMP objects from libc.a.
>>>
>>> Generically, any test using any objects from libc.a will have problems if 
>>> those reference hidden symbols (in this case, __assert_fail) from 
>>> elsewhere in libc.
>>
>> I don't think linking a test both against libc.a and libc.so is valid.
>>
>> In other cases, in order to test hidden symbols, we use fully static
>> linking instead.  Is this something we could do here as well?  I don't
>> think it would invalidate the tests any more than the current hybrid
>> linkage model does.
> 
> As far as I know, linking those tests statically would be OK (it would not 
> significantly affect what they are testing).  That's atext-exp, 
> atest-sincos, atest-exp2 that are using internal GMP objects from libc.a; 
> I don't know if other tests, in math/ or elsewhere, also link against 
> particular libc.a objects.

I think the attached approach will work for the math subdirectory.
Tested on aarch64 and ppc64le.

I see additional aarch64 failures, though (outside math).

Thanks,
Florian
  

On 08/22/2017 12:47 PM, Florian Weimer wrote:
> I think the attached approach will work for the math subdirectory.
> Tested on aarch64 and ppc64le.
> 
> I see additional aarch64 failures, though (outside math).

The failure was spurious (probably clock skew).

I have since tried “make xcheck” and “make bench-build” on both
architectures and don't see any failures anymore with the patch I posted
(and the revert reverted).

Thanks,
Florian
  

On Tue, 22 Aug 2017, Florian Weimer wrote:

> > As far as I know, linking those tests statically would be OK (it would not 
> > significantly affect what they are testing).  That's atext-exp, 
> > atest-sincos, atest-exp2 that are using internal GMP objects from libc.a; 
> > I don't know if other tests, in math/ or elsewhere, also link against 
> > particular libc.a objects.
> 
> I think the attached approach will work for the math subdirectory.
> Tested on aarch64 and ppc64le.
> 
> I see additional aarch64 failures, though (outside math).

To be clear: it works for math/ on top of having reapplied HJ's patch, but 
there are still similar failures in other directories (on aarch64) in the 
presence of HJ's patch?

What are those other aarch64 failures?  Maybe we should look at the full 
set of failures in all directories with the visibility changes in order to 
figure out what approaches are good for fixing such problems.

In principle it should make sense for all symbols in the static libraries 
to be hidden (maybe build them with -fvisibility=hidden?), unless there's 
a specific reason some given symbol needs to be non-hidden for normal use 
of the installed libraries, but first we need to sort out any testsuite 
breakage that causes.
  

On 08/22/2017 01:39 PM, Joseph Myers wrote:
> On Tue, 22 Aug 2017, Florian Weimer wrote:
> 
>>> As far as I know, linking those tests statically would be OK (it would not 
>>> significantly affect what they are testing).  That's atext-exp, 
>>> atest-sincos, atest-exp2 that are using internal GMP objects from libc.a; 
>>> I don't know if other tests, in math/ or elsewhere, also link against 
>>> particular libc.a objects.
>>
>> I think the attached approach will work for the math subdirectory.
>> Tested on aarch64 and ppc64le.
>>
>> I see additional aarch64 failures, though (outside math).
> 
> To be clear: it works for math/ on top of having reapplied HJ's patch, but 
> there are still similar failures in other directories (on aarch64) in the 
> presence of HJ's patch?

See my other message.

Initially, I saw another build failure (with HJ's patch re-applied), but
I can't reproduce it.  I don't see any check/xcgeck/bench-build failures.

I did not check s390x, ppc, ppc64, though.  (Our lab automation is a bit
overloaded right now, so I can't get a machine reservation easily.)

But I think it should be possible to apply my patch and revert the revert.

Thanks,
Florian
  

On Tue, 22 Aug 2017, Florian Weimer wrote:

> On 08/22/2017 12:47 PM, Florian Weimer wrote:
> > I think the attached approach will work for the math subdirectory.
> > Tested on aarch64 and ppc64le.
> > 
> > I see additional aarch64 failures, though (outside math).
> 
> The failure was spurious (probably clock skew).
> 
> I have since tried “make xcheck” and “make bench-build” on both
> architectures and don't see any failures anymore with the patch I posted
> (and the revert reverted).

Thanks.  This patch (and restoring HJ's patch) is OK to allow continued 
progress on the visibility changes (although the alternative of using 
mini-gmp in these tests is attractive as well, in line with the general 
principle of limiting tests to using public interfaces when they have no 
real need for internal interfaces).