On Tue, Jun 10, 2014 at 9:01 PM, Andrei Gherzan <and...@gherzan.ro> wrote:
> > > > On Mon, Jun 2, 2014 at 4:18 AM, Alex J Lennon < > ajlen...@dynamicdevices.co.uk> wrote: > >> >> On 01/06/2014 22:35, Alex J Lennon wrote: >> >> >> On 01/06/2014 22:22, Alexandru Vaduva wrote: >> >> This are indeed some very good news Alex J Lennon. >> I have some questions, but those maybe can be answered by the >> maintainers of the meta-raspberrypi layer: >> Why was this change done? >> -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp" >> -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp" >> +PREFERRED_PROVIDER_virtual/egl ?= "userland" >> +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland" >> How it may affect other applications? >> Andrei: Do you have any input on this? >> >> >> >> I think I've worked out what is happening. It looks like an interesting, >> and pretty obscure, effect of the default bitbake linker flags. >> >> There's an __attribute__(constructor) decorated function that is supposed >> to be executed when libmmal_vc_client.so is loaded. >> >> However by default bitbake passes in LDFLAGS of --as-needed which means >> that although raspivid is set to be linked against libmmal_vc_client, the >> dependency, which is un-needed by raspivid as there's no call into that >> library, is removed. >> >> The userland code for Raspivid tries to create a component with a call >> to mmal_component_create() which is in libmmal_core >> >> ref: >> https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c >> >> This function goes to a default constructor which walks a list >> mmal_component_supplier_create(const char *name, MMAL_COMPONENT_T >> *component) >> >> ref: >> https://github.com/raspberrypi/userland/blob/master/interface/mmal/core/mmal_component.c >> >> The function that populates the supplier list, >> mmal_component_supplier_register(), is called from a function in another >> library, libmmal_vc_client, which is decorated with >> >> MMAL_CONSTRUCTOR(mmal_register_component_videocore); >> >> which is defined as >> >> # define MMAL_CONSTRUCTOR(func) void __attribute__((constructor,used)) >> func(void) >> >> i.e. This registration function would normally execute when the library >> it lives in is loaded, but because there's no call into that library from >> raspivid, and because we linked with --as-needed, the library is removed >> from the executable's dependency list, and the components are never >> registered... >> >> Diffing the working and non-working raspivids, >> >> Dynamic Section: >> NEEDED libmmal_core.so >> NEEDED libmmal_util.so >> - NEEDED libmmal_vc_client.so >> NEEDED libvcos.so >> >> So if I modify the userland_git.bb to remove the --as-needed >> >> +LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu" >> >> With this change I can now build userland out of meta-raspberrypi and >> raspivid works for me. >> >> Cheers, >> >> Alex >> >> >> >> >> > > I managed to get in sync with this discussion and will come with some > clarifications. > > We switched to userland because that should give the user the best > customization for graphics libraries. So as long as we have the sources > would be strange not to use it. But if user doesn't want to compile the > graphics libraries, can overwrite the PREFERENCE as needed. But generally > building packages from source would avoid incompatibilities and some of the > issues (linkage etc). But this is an example which proves that this can add > issues too. > > Now specific to this problem, I understand it, and the the fix that > follows this discussion seems to be right. Just heading to merges. Thanks a > lot guys (sorry for delay - will try to be more responsive). > I merged the patches but there is a strange behavior. With --as-needed removed i still get the unneeded dependency. 0x00000001 (NEEDED) Shared library: [libmmal_core.so] 0x00000001 (NEEDED) Shared library: [libmmal_util.so] 0x00000001 (NEEDED) Shared library: [libmmal_vc_client.so] 0x00000001 (NEEDED) Shared library: [libvcos.so] 0x00000001 (NEEDED) Shared library: [libbcm_host.so] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [librt.so.1] 0x00000001 (NEEDED) Shared library: [libvchiq_arm.so] 0x00000001 (NEEDED) Shared library: [libc.so.6] Alex, can you take another look on this? It seems like somehow the fix doesn't work for me. -- *Andrei Gherzan* m: +40.744.478.414 | f: +40.31.816.28.12
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
