[Mesa-dev] The long way to a faster build with shared libs and some fixes ...

[Mathias Fröhlich]

Hi,

On Thursday, September 12, 2013 08:41:10 Christian König wrote:
> I completely agree.
> 
> Building everything shared might speed up the build process a little bit
> and save some space, but for the cost of having to handle allot of
> rather small shared libraries where which each clashing the symbol space
> of any application using these drivers with a bunch of unnecessary symbols.
> 
> Building everything as one big blob sounds like the better idea.
+1.

Symbol clashes with libraries used in drivers are a huge problem for 
applications that either ship with their own version/variant of this kind of 
library and do not expect to have a second one injected by the side effect of a 
user space driver or in case of LLVM just because of this not being reliably 
thread safe. If your driver knows the version and instance of llvm it has 
linked with, because it's its own internal one technically hidden from all 
other potential users we will see less unwanted side effects.

To get this symbol clash problem right, there could be an other solution I 
have been playing with which is loading the drivers with RTLD_DEEPBIND. I am 
running with patches for this already for a long time here but I never found 
the time to test this for side effects on OpenCL use. The problem that still 
needs to be investigated there is that you want to share buffer objects between 
OpenCL and OpenGL and for that you work you might(?) need a single instance of 
libdrm in the application. Also this dlopen flag is not part of the standard 
that covers dlopen and thus not avaiable everywhere.

What problem do you want to solve exactly with this shared library split?

If you care for memory use of the running application, you will need to have 
the driver binary loaded including all its code. Having a big blob without any 
relocs in between increases the probability that you can reuse read only pages 
for the code segments to be shared between applications.
Note that the RTLD_DEEPBIND variant above uses even more memory in the running 
application since each dlopened driver gets it's own private set of mapped 
shared objects.

If you care about on disc use which might be interresting for small embedded 
like machines, is it possible to split the drivers rpm into seperate pieces 
per driver? That way an embedded system integrator could potentially install 
them individually based on the available hardware for such a specific case?

Greetings

Mathias