[Pixman] [PATCH 1/4] test: static link pixman in matrix-test

[Emil Velikov]

Hello Siarhei,

On 26 April 2016 at 19:32, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> Hello Emil,
>
> On Sun, 24 Apr 2016 19:20:58 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> The test uses pixman internal symbols, which we currently export. To
>> resolve that static link the pixman library. This is an internal only
>> test ran at `make check' thus we are fine with the bloated binary and
>> alike.
>>
>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>> ---
>> Afaics the Windows build already uses a static library thus things
>> should be fine there. I have NOT tested it though.
>>
>> If people are concerned with this approach, we can build the core files
>> once and explicitly setup a pixman-static.la for the tests to use.
>> ---
>>  test/Makefile.am | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/test/Makefile.am b/test/Makefile.am
>> index 88dc36d..f70440e 100644
>> --- a/test/Makefile.am
>> +++ b/test/Makefile.am
>> @@ -5,6 +5,8 @@ AM_LDFLAGS = $(OPENMP_CFLAGS) $(TESTPROGS_EXTRA_LDFLAGS) $(PTHREAD_LDFLAGS)
>>  LDADD = libutils.la $(top_builddir)/pixman/libpixman-1.la -lm  $(PNG_LIBS) $(PTHREAD_LIBS)
>>  AM_CPPFLAGS = -I$(top_srcdir)/pixman -I$(top_builddir)/pixman $(PNG_CFLAGS)
>>
>> +matrix_test_LDFLAGS = -static
>> +
>>  libutils_la_SOURCES = $(libutils_sources) $(libutils_headers)
>>
>>  noinst_LTLIBRARIES = libutils.la
>
> Well, I have only one question. Where is the profit and what are we
> supposed to gain by applying patches from this series?
>
> Right now if you are interested in compiling static test programs,
> then you can use the --enable-static-testprogs configure option.
> It is useful for running the pixman test suite under QEMU with the
> help of binfmt_misc.
>
> And we currently also can run the test suite against pixman shared
> libraries, which are built and shipped as binary packages by various
> Linux distributions. In the case if some distribution maintainers are
> up to no good [1], this still allows us to confirm whether they are
> shipping broken pixman binaries even without any need to figure out
> how to use their build infrastructure.
>
> If I understand it correctly, you are basically trying to go an
> extra mile to remove the existing diagnostic interface from the
> pixman shared library. Would we lose anything if we just keep
> things working as they are?
>
Precisely - it aims to remove the unneeded exports.

Exporting symbols only to call them "internal only" does seem a bit
wrong. It also opens the door for (in)intentional abuse. Let's not
forget that one of them does not even have the "internal only" tag in
its name.

While I can see your point about running the tests against system
pixman, I'm not sure how much in reality that is an actual thing.
Afaict everyone building pixman must run `make check' (without -k of
course) to ensure that they have a properly working binary. That's the
point of `make check', isn't it ? If they don't ... then they are just
asking for trouble.

Obviously the size of the final binary was (slightly) improved, but
I'm not sure how much you're going to buy that as an argument.

Regards,
Emil