This is the mail archive of the 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:40 PM, Joseph Myers <> wrote:
> On Mon, 21 Aug 2017, H.J. Lu wrote:
>> > 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.
> That seems like a workaround rather than a proper fix for this issue.

It is a workaround for the issues in those tests so that the valid optimization
in libc can enabled.

>> 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
> The point isn't to access internal interfaces of libc.  It's to access
> multiple-precision functionality that happens to be present in libc, in
> order to use it for a different purpose (to cross-check libm function
> implementations).  I don't think we should export interfaces only used by
> tests; GLIBC_PRIVATE should be for interfaces used by other shared
> libraries.
> Now, it would be reasonable to build those GMP files again (configured as
> in-testsuite not in-libc) just for use in those tests.  That might be the
> cleanest approach for avoiding the problem, but it might also run into
> other problems if building those files as in-testsuite doesn't actually
> work because they depend on internal details of headers that are disabled
> for the in-testsuite case.

Why not require and use the real gmp library for those tests?


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