On 5 September 2013 13:23, Phil Blundell <[email protected]> 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.
There won't be any problems with dlopen() because that only looks at .so files. Any issues will be at build time, I wouldn't be surprised if some dependencies changed due to a difference in eg pkgconfig vs .la linkage. Then again some other distros blanket-delete .la files by default so I don't expect any critical problems. >> * 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. I don't think a distro feature is the right approach, but however it's set can easily be forced using a machine override for Darwin. Ross _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
