This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [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.


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