This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add hidden visibility to internal function prototypes
On Mon, Aug 21, 2017 at 2:15 PM, Joseph Myers <joseph@codesourcery.com> 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;
Linking against both libc.a and libc.so isn't supported since many data
structures are defined in different places in libc.a and libc.so.
> I don't know if other tests, in math/ or elsewhere, also link against
> particular libc.a objects.
>
I am testing a patch to provide a simple __assert_fail implementation for
these math tests.
Personally, I believe these tests are wrong. if we need to access the
internal interfaces of libc, we should export them as private interface,
not by abusing libc.a and libc.so.
--
H.J.