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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev