[Mesa-dev] [PATCH 16/23] targets/vdpau: convert to static and shared pipe-drivers

[Jonathan Gray]

On Sun, May 18, 2014 at 09:44:00AM +0100, Emil Velikov wrote:
> On 18/05/14 08:41, Jonathan Gray wrote:
> > On Sun, May 18, 2014 at 08:07:38AM +0100, Emil Velikov wrote:
> >> Create a single library containing the state-tracker etc.
> >> thus have a smaller overall size footprint of mesa.
> >>
> >> The driver can be built with the relevant pipe-drivers
> >> statically linked in, or loaded as shared modules.
> >> Currently we default to static link.
> >>
> >> Add SPLIT_TARGETS to guard the other VL targets.
> >>
> >> Note: symlink handling is rather ugly at the moment due
> >> to versioning of the libvdpau library. Tested only on
> >> linux plarform. BSD and other platforms will likely need
> >> and update.
> > 
> > Given these links will fail and break builds perhaps
> > only do them on systems where the library versioning
> > is known to work like it does on linux, otherwise
> > install multiple copies of the library?
> > 
> > That or find a way to get libtool to create them.
> > 
> Hi Jonathan,
> 
> Just had a look but did not manage to see a OpenBSD repo that uses latest (or
> 10+ era) mesa.
> 
> I was looking for the targets which are built under OpenBSD, although
> xanocara's mesa 9.2.x is not too informative.

I have an updated set of xenocara makefiles for Mesa 10.2 that I
haven't put up yet, those will be committed after a newer
Mesa release is imported.  Thanks to the loader changes
libgbm can even be included allowing glamor to work.

The 'src' tree in OpenBSD is self contained and contains all
of the tools required to build itself.  The 'xenocara' tree
contains X11 related parts and can only depend on other things
in the xenocara and src trees.  Packages are built
from the 'ports' tree which has makefiles/patches for building
things but does not include the source to the packages directly
unlike the src and xenocara trees.

That is why Mesa in xenocara has a seperate set of makefiles,
otherwise we would have to import python, gnu make, and other
things which isn't going to happen.

To try to reduce the pain in doing this I do builds of
Mesa every so often using the autotools setup.  With a
collection of various patches. The patches can be found here:
https://github.com/jonathangray/mesa/commits/fixes
not all of them are appropriate for the main Mesa tree.

> 
> - Which of the targets addressed in these series are built/used with OpenBSD ?

Currently I run my autotools builds like this:

export LDFLAGS=-L/usr/local/lib
export CPPFLAGS="-I/usr/local/include -I/usr/local/include/libelf"
export AUTOMAKE_VERSION=1.12
export AUTOCONF_VERSION=2.69
export LEX=/usr/local/bin/gflex
./autogen.sh \
--with-gallium-drivers=r300,r600,radeonsi,swrast,nouveau \
--with-dri-drivers=i915,i965,r200,radeon,swrast \
--disable-silent-rules \
--enable-r600-llvm-compiler --enable-gallium-llvm \
--disable-llvm-shared-libs \
--enable-gles1 --enable-gles2 \
--enable-shared-glapi \
--disable-osmesa \
--enable-debug \
--enable-gbm \
--with-egl-platforms="x11,drm" \
--prefix=/usr/mesa

> - Do you have a link/spec/doc that I can lookup the platform's shared library
> versioning scheme ?

It is sunos 4.x style versioning, where as Linux seems to use System V style?
Libraries are all libfoo.so.major.minor with no revision and no symlinks.
ld.so will search for the newest library with "libfoo.so.major" or the like
but "libfoo.so.major" never exists on the filesystem.

The OpenBSD scheme is a simplified one with no symbol versioning,
so DT_SONAME doesn't make a lot of sense.
ELF shared libraries do not have DT_NEEDED entries for libc by design
(which is why the configure script doesn't use -Wl,--no-undefined on OpenBSD).

I suspect FreeBSD/NetBSD work in a similiar manner given FreeBSD couldn't
build Mesa without symlink related patches some time ago.  Though FreeBSD
apparently have introduced symbol versioning and changed the behaviour
when they switched to ELF.

Shared libraries are briefly mentioned here
http://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
similiar text for FreeBSD can be found here
https://www.freebsd.org/doc/en/books/developers-handbook/policies-shlib.html

> - Are you aware of any projects that go through these hoops (hardlinks +
> versioned fun) that I can get some inspiration from ?

Libtool, cmake and other things along those lines, but anything
that builds shared libraries and doesn't use those likely
contains some knowledge of how to construct names for
Mac OS X, windows, linux, bsd etc as they all seem to be different.