Using the following in my build and installation script: setLibdir="/patate/lib/mesa/" execPrefixInstallDir="/patate/lib/mesa" PrefixInstallDir="/patate/lib/mesa" and execConfigCmd="$baseConfigCmd --build=$setBuild --host=$setHost --libdir=$setLibdir --exec-prefix=$execPrefixInstallDir --prefix=$PrefixInstallDir" All the files are to be installed under /patate/lib/mesa when testing with "make -n install", except files related to omx state tracker. Their installation folder keeps pointing to /usr/lib/bellagio. (see attached installation log file) When crosscompiling, it always points to /usr/lib32/bellagio, which is also wrong.
Created attachment 101899 [details] make -n install result omx tracker doesn't respect specified installation folder. Look for bellagio VS any other file (dri, gbm, etc.)
AFAIK the issue here is that bellagio dictates where the plugins must be installed - pkg-config --variable=pluginsdir libomxil-bellagio If that location is incorrect you can workaround by setting the following at configure time --with-omx-libdir Marking this as "not a bug" although feel free to reopen if the latter does not help.
That's something I hadn't noticed. However, it still bugs me. Why would this component deal with its installation path differently from the others. Let's have a look at opencl, vdpau and egl : --with-vdpau-libdir=DIR directory for the VDPAU libraries [default=${libdir}/vdpau] --with-opencl-libdir=DIR directory for auxiliary libraries used by the OpenCL implementation [default=${libdir}/opencl] --with-egl-driver-dir=DIR directory for EGL drivers [[default=${libdir}/egl]] And then we have omx : --with-omx-libdir=DIR directory for the OMX libraries It seems omx is one of a kind by not using something ${libdir}/bellagio. By doing this small modification, a user wouldn't be surprise to have this only component install not in the libdir he asked for, but he would still be able to set a different path if needed. I'm reopening this bug so that the default libdir for omx be set to default=${libdir}/bellagio, as expected from other components. That way, no surprise for anybody because everything will follow the same rule, but the user will keep a way to change specifically this installation folder by using --with-omx-libdir. I'll propose a patch for this modification later today.
Emil, I just sent a patch on mesa-dev, but maybe I should have included you in CC though. See http://lists.freedesktop.org/archives/mesa-dev/2014-June/062477.html
AFAICS the whole thing is quite inconsistent. (In reply to comment #3) > That's something I hadn't noticed. However, it still bugs me. Why would this > component deal with its installation path differently from the others. Let's > have a look at opencl, vdpau and egl : > --with-vdpau-libdir=DIR directory for the VDPAU libraries > [default=${libdir}/vdpau] Defined by libvdpau. Can be accessed/queried via pkg-config (moduledir) > --with-opencl-libdir=DIR > directory for auxiliary libraries used by the > OpenCL > implementation [default=${libdir}/opencl] Unused. > --with-egl-driver-dir=DIR > directory for EGL drivers [[default=${libdir}/egl]] > Internal to mesa. Ideally we'll have this one nuked for the next release. > And then we have omx : > --with-omx-libdir=DIR directory for the OMX libraries > Defined by bellagio. Can be accessed/queried via pkg-config (pluginsdir) > It seems omx is one of a kind by not using something ${libdir}/bellagio. By > doing this small modification, a user wouldn't be surprise to have this only > component install not in the libdir he asked for, but he would still be able > to set a different path if needed. > It can be argued either way, yet imho we should be using pkg-config when possible. I don't mind either way, as long as Christian is happy with the solution.
Christian, could you give us your input on this issue and proposed fix? (In reply to comment #5) > AFAICS the whole thing is quite inconsistent. > > (In reply to comment #3) > > That's something I hadn't noticed. However, it still bugs me. Why would this > > component deal with its installation path differently from the others. Let's > > have a look at opencl, vdpau and egl : > > --with-vdpau-libdir=DIR directory for the VDPAU libraries > > [default=${libdir}/vdpau] > Defined by libvdpau. Can be accessed/queried via pkg-config (moduledir) > > > --with-opencl-libdir=DIR > > directory for auxiliary libraries used by the > > OpenCL > > implementation [default=${libdir}/opencl] > Unused. > > > --with-egl-driver-dir=DIR > > directory for EGL drivers [[default=${libdir}/egl]] > > > Internal to mesa. Ideally we'll have this one nuked for the next release. > > > And then we have omx : > > --with-omx-libdir=DIR directory for the OMX libraries > > > Defined by bellagio. Can be accessed/queried via pkg-config (pluginsdir) > > > It seems omx is one of a kind by not using something ${libdir}/bellagio. By > > doing this small modification, a user wouldn't be surprise to have this only > > component install not in the libdir he asked for, but he would still be able > > to set a different path if needed. > > > It can be argued either way, yet imho we should be using pkg-config when > possible. I don't mind either way, as long as Christian is happy with the > solution.
(In reply to comment #5) > AFAICS the whole thing is quite inconsistent. The problem with bellagio is that the plugin directory isn't standarized over the different distributions like it is with vdpau/egl/etc... So you can't define a default value like ${libdir}/bellagio and expect it to work. So the only option to make it consistent would be by moving vdpau/egl/etc... to the same behavior.
Just sent out a few patches which should address all the points raised. Feel free to give them a try :) http://patchwork.freedesktop.org/patch/33915/ http://patchwork.freedesktop.org/patch/33916/ http://patchwork.freedesktop.org/patch/33917/
I've pushed all three patches which should resolve the issues. Whereas "why we honor the variables in pkgconfig rather than libdir,{exec-}prefix": All of the cases touches used the folder mentioned in pkgconfig to construct the full file path and dlopen the module. LD_PRELOAD and LD_LIBRARY_PATH does not help here. I realise it's not the recommended way (i.e. install everything in prefix) yet it's the only sensible way to get it to work properly without relying on nasty hacks :\
Thanks for letting me know. I'll have a look at the result soon enough. ;)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.