Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc 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 datastructures 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 forthese math tests.Personally, I believe these tests are wrong. if we need to access theinternal interfaces of libc, we should export them as private interface,not by abusing libc.a and libc.so.-- H.J.
[8]ページ先頭