[Mesa-dev] libxatracker: automake and spurious symbols

[Emil Velikov]

On 29/03/14 14:24, Kai Wasserbäch wrote:
> Hi Emil,
> Emil Velikov schrieb am 29.03.2014 14:21:
>> On 29/03/14 12:37, Kai Wasserbäch wrote:
>>> I saw one of your patches currently in review touching the Makefile.am of
>>> libxatracker. Can you squeeze in another patch, that ensures, that the library
>>> only exports its own symbols and not the entirety of LLVM as well? Because
>>> somewhere between 4c79f088c0 and 9b6b084eb7, that started to happen. My
>>> 4c79f088c0 build only exported symbols for xa_* functions, the current build of
>>> 9b6b084eb7 adds some ten thousand LLVM symbols.
>>>
>> Yes that is the privilege of using LLVM, you export the whole LLVM world as
>> soon as you go anywhere near it :P
>>
>> My initial plan was to do another round of "cleanup the exported symbols"
>> but got sidetracked by stripping out duplication and making sure that the
>> libraries just work (tm).
>>
>>> I tried a version script and and -export-symbols-regex '^xa_.*$$', which really
>>> got added to the linking command, according to the build log, but didn't have
>>> any impact on the actually exported symbols. I'm probably missing something as
>>> I'm not too well versed in how to do things with Automake.
>>>
>> Strange... things were working fine last time I've checked. While I try to
>> reproduce what build options are you using, LLVM version ? Can I take a look
>> at the patch that you've used ?
> 
> Sure. I've tried several variants of the attached
> "0001-Build-libxatracker-Only-export-our-own-symbols.patch", where I replaced
> "LDFLAGS" with "AM_LDFLAGS" and "libxatracker_la_LDFLAGS". The last didn't work
> at all and Automake warned, that no library is using the name libxatracker_la,
> even though just a few lines up there was "libxatracker_la_SOURCES". I also
> tried listing all symbols explicitly in the version script, but that didn't
> change anything either.
> 
> The second approach was really just patching the Makefile to add the
> -export-symbols-regex '^xa_.*$'
> to the LDFLAGS. I did it the same way, it's used with the OMX stuff, see the
> attached patch "0001-Build-libxatracker-pass-export-symbols-regex-to-link.patch"
> 
The key issue with your approach is that you're restricting the exported
symbols at the wrong "level". One should work on the finished target, as this
is where all the linking (inc. the one against LLVM) happens. I will prep a
series that clears the exported symbols in a more consistent way all across
all gallium targets.

> As far as my build goes, I'm using the following configure options (basically
> what Debian's mesa package uses, except, that I'm using a development snapshot
> of LLVM 3.5, and compile LLVM in statically – I was unable to configure Mesa
> against Debian's LLVM package for dynamic linking, unless I would patch the
> configure.ac):
> configure --prefix=/usr --mandir=\${prefix}/share/man \
>   --infodir=\${prefix}/share/info --sysconfdir=/etc \
>   --libdir=\${prefix}/lib/x86_64-linux-gnu \
>   --localstatedir=/var --disable-silent-rules \
>   --build=x86_64-linux-gnu --enable-dri --with-dri-drivers=" nouveau i915 i965
> r200 radeon" \
>   --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri \
> 
> --with-dri-searchpath='/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri' \
>   --enable-osmesa --enable-glx-tls --enable-shared-glapi --enable-texture-float
> --enable-xa \
>   --disable-xvmc --enable-driglx-direct --enable-dri3 --with-egl-platforms="x11
> drm wayland" \
>   --enable-opencl --enable-opencl-icd --enable-gallium-llvm --enable-vdpau \
>   --with-gallium-drivers=" nouveau svga swrast r600 r300 radeonsi" --enable-gles1 \
>   --enable-gles2 --enable-openvg --enable-gallium-egl \
>   CFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -Wall" \
>   CPPFLAGS="-D_FORTIFY_SOURCE=2" \
>   CXXFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -Wall" \
>   FFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4" \
>   GCJFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4"
> LDFLAGS="-Wl,-z,relro"  \
>   --disable-llvm-shared-libs \
^^ This bad boy is causing all the problems. By default we're using shared
libs, so most people should not see any of the llvm chaos.

I'm not entirely sure why you insist on using it, but I hope you can live with
all the extra symbols for a little longer :P

>   ac_cv_path_LLVM_CONFIG=llvm-config-3.5
> 
> LLVM is at SVN:trunk/r204915 (the packages from <http://llvm.org/apt>, which are
> maintained by Debian's LLVM maintainer).
> 
I guess he may have an idea why every piece of software static linking against
llvm has to use version scripts/etc. If we can avoid all this madness that
would be even better :)

>> Btw. feel free Cc the ML as other people may have spotted/resolved this
>> (kind of) issue(s). Even if I cocked up something I do not mind being called
>> out :)
> 
> Done.
> 
>> ...
>> Hmm I cannot see how any of the commits in that range may be causing such
>> problem. Can you please confirm that it's not a "stale file" issue - git
>> clean -nxd should help out.
> 
> Yes, I'm sure of that. I'm always building in a clean chroot with pbuilder. No
> stale files around.
> 
>> P.S. Why does BlunderBird throws a hissy fit when replying to a signed emails.
>> It's not like it's a "new and unknown thing". Am I asking for too much ?
> 
> Do you have Enigmail installed?
> 
Yes I do. In order to get it working properly I needed to switch off an hidden
feature :)

-Emil

> Cheers,
> Kai
> 
> 
>