Re: [PATCH 2/4] xorg-driver-common: Add configure and install appends from meta-intel

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2013-09-05 at 13:23 +0100, Phil Blundell wrote:
> On Thu, 2013-09-05 at 13:14 +0100, Richard Purdie wrote:
> > * Figuring out any runtime issues with dlopen is the hardest part and we
> > don't actually have real data on whether there are issues there or not.
> 
> Do we have any particular reason to believe that there would be issues
> (and if so, what they might be)?  I guess it should be easy enough to
> gather data if we know what we're looking for.
> 
> Right now the .la files go into the -dev packages anyway and hence
> aren't usually going to be available at runtime for anything calling
> dlopen() on the target.  Is it native packages you're concerned about?

The -dev package argument is a good one, we seem to be surviving without
those and that probably addresses the concern I was thinking of. I'm
also thinking of ltdl and its dlopen wrapping, not dlopen itself which
is a much smaller subset of recipes.

> > * We'd be deviating from the way the libtool authors suggest their tool
> > should operate. This makes filing bug reports and interacting with
> > upstream harder. 
> 
> This is true, though interacting with libtool upstream already seems to
> be hard enough that I'm not sure this would make a material difference.

It does seem somewhat tricky, agreed.

> > * They are used in places, for example the darwin shlibs code currently
> > uses them. It could be updated to use otool these days mind but I'd
> > probably make the current code a fallback for unknown arches since it is
> > guaranteed to work everywhere.
> 
> There's no reason in principle that folks on darwin (and/or
> hitherto-undiscovered architectures) couldn't retain the .la files if
> they wanted.  The original patch that I sent used a DISTRO_FEATURE to
> control this and those people building for darwin could simply refrain
> from setting it.  Alternatively we could make it explicitly conditional
> on TARGET_OS or some such if there are reasons to believe that some
> targets do genuinely require this stuff.

There are ways to avoid problems for darwin. Using otool instead of
the .la files would be nice, equally mangling DISTRO_FEATURES based on
an SDK override is possible, albeit ugly. The la handling code will
likely bitrot as soon as its disabled by default and metadata starts
getting dropped which is probably a bigger concern. The number of SDK
darwin builds is currently a tiny portion of the usercase and codebase.

I guess the .la files just don't seem to be a big issue that some people
seem to paint them as. Why do we need to remove them and deviate from
the upstream?

Anyhow, if someone can show some world builds with and without the .la
files and see what build history shows we'd be closer to taking a patch
to turning them off. If we do it, we'll have to do it everywhere for
everything since the remaining code will bitrot badly IMO otherwise.

Cheers,

Richard