[Mesa-dev] Please test the automake-gallium4 branch

[Emil Velikov]

On 03/12/12 01:42, Marek Olšák wrote:
> On Mon, Dec 3, 2012 at 2:30 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 03/12/12 00:15, Marek Olšák wrote:
>>> On Sun, Dec 2, 2012 at 9:48 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> On 23/11/12 21:23, Andreas Boll wrote:
>>>>> Hi mesa-list,
>>>>>
>>>>> I'm happy to announce that I've finished Matt's automake-gallium branch [0].
>>>>> Some of the independent patches are already in the master branch.
>>>>> I've fixed the missing symbols in vdpau and xvmc
>>>>> and installed lots of compatibility links to provide the same
>>>>> behaviour as the old build system. (lib/*.so and lib/gallium/*.so)
>>>>>
>>>>> Please help Matt and me to test the automake-gallium4 branch [1] !
>>>>>
>>>>> Here you have a list of things you could test:
>>>>>
>>>>> Drivers:
>>>>> - i915g
>>>>> - llvmpipe
>>>>> - nv30
>>>>> - nv50
>>>>> - nvc0
>>>>> - r300g
>>>>> - r600g
>>>>> - radeonsi
>>>>> - softpipe
>>>>> - svga
>>>>>
>>>>> State tracker:
>>>>> - Clover (OpenCL)
>>>>> - Mesa (OpenGL)
>>>>> - VDPAU
>>>>> - Vega (OpenVG)
>>>>> - XA
>>>>> - Xorg
>>>>> - XvMC
>>>>>
>>>>> The other build systems:
>>>>> - Android
>>>>> - Scons
>>>>>
>>>>> Some other things:
>>>>> - egl, gles1,2, gbm, with and without LLVM, r600-llvm-compiler
>>>>>
>>>>>
>>>>> If there are no objections I'll merge this branch next week.
>>>>>
>>>>> Thanks to Matt and Tom for the hard work.
>>>>
>>>> Hi Andreas
>>>>
>>>> I've been testing the branch for a few days now and apart from the
>>>> increased number of symbols [1] I have not noticed any issues
>>>>
>>>> * Hardware - nvidia geforce GT 120M (nv96)
>>>> * Drivers - nv50
>>>> * State trackers - Mesa/Gallium (OpenGL)
>>>>
>>>> The following have also been built but not tested (yet)
>>>> * egl, gles1,2, gbm, vdpau
>>>>
>>>> [1] The number and type of symbols varies greatly. The following are
>>>> mostly affected
>>>
>>> How exactly does it vary? AFAIK the current build system uses a gcc or
>>> linker flag to hide most of the symbols.
>>
>> A nice example is swrast_dri.so (oops forgot to mention it)
>> 215 vs 1962 is the count of dynamic symbols before and after automake
>>
>> A brief list of the new symbols
>>
>>        D  *UND* 0000000000000000              _glapi_set_dispatch
>>        D  *UND* 0000000000000000              _glapi_tls_Dispatch
>> + g    DF .text 0000000000000002  Base        draw_create
>> + g    DO .data.rel.ro  00000000000000d8  Base
>> util_format_l32_uint_description
>> + g    DF .text 0000000000000105  Base
>> util_format_dxt1_rgb_unpack_rgba_8unorm
>> + g    DO .data.rel.ro  00000000000000d8  Base
>> util_format_r8g8b8a8_uscaled_description
>> + g    DF .text 00000000000000a5  Base        trace_dump_ret_end
>> + g    DF .text 000000000000006c  Base        ppc_comment
>> + g    DF .text 00000000000000ff  Base        draw_pipeline_run_linear
>> + g    DF .text 000000000000119a  Base        u_index_init
>> + g    DF .text 0000000000000081  Base        x87_fsubp
>>
>> I can provide more info but not too sure where to start
>> * compiler
>> * linker
>> * build flags...
> 
> Try -fvisibility=hidden. The flag is very important for linux
> distributions, because it makes the libs smaller.
> 
> configure.ac sets it. I think the automake build system ignores it,
> which is a bug.
> 

Major improvement, although some interesting symbols appeared

swrast_dri.so: cff4c94 vs 02d36a2 (with -fvisibility=hidden)

...
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 exp
+0000000000000000      DF *UND*	0000000000000000  GLIBC_2.3.2
pthread_cond_destroy
+0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 sincosf
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 atan2
...
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 puts
+0000000000000000      DF *UND*	0000000000000000  GLIBC_2.3.2
pthread_cond_signal
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 log2f
...
 0000000000000000      D  *UND*	0000000000000000
_glapi_get_proc_address
+0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 sched_yield
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.3.4 __memcpy_chk
...
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.3.4 __strncat_chk
+0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 log
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 logf
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 strtod
 0000000000000000      DO *UND*	0000000000000000  GLIBC_2.2.5 stdout
+0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 _IO_putc
 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 fflush
 0000000000000000      D  *UND*	0000000000000000
_glapi_tls_Dispatch
-000000000020fb40 g    DF .text	0000000000002794  Base        glcpp_lex
-000000000020f0e0 g    DF .text	0000000000000008  Base        glcpp_set_lval
-000000000020f110 g    DF .text	0000000000000005  Base        glcpp_alloc

AFAIK the lack of glcpp_* should not cause any issues. I'm a bit curious
what caused sched_yield and pthread_cond_* to pop in. Either case I will
give a bit of love to see if any issues do arise

Andreas
I have noticed that some of the latest egl-static patches caused
egl_gallium.so to disappear(?). Not too sure is it the Arch way of
packaging or genuine issue. I'll investigate as time permits


Thanks
Emil
> Marek
>