Bug 80615 - Files in bellagio directory [omx tracker] don't respect installation folder
Summary: Files in bellagio directory [omx tracker] don't respect installation folder
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-28 00:47 UTC by Alexandre Demers
Modified: 2014-09-27 21:46 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
make -n install result (97.16 KB, text/plain)
2014-06-28 00:55 UTC, Alexandre Demers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Demers 2014-06-28 00:47:50 UTC
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.
Comment 1 Alexandre Demers 2014-06-28 00:55:52 UTC
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.)
Comment 2 Emil Velikov 2014-06-28 01:30:28 UTC
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.
Comment 3 Alexandre Demers 2014-06-29 16:00:17 UTC
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.
Comment 4 Alexandre Demers 2014-06-30 21:09:27 UTC
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
Comment 5 Emil Velikov 2014-06-30 21:23:20 UTC
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.
Comment 6 Alexandre Demers 2014-07-25 06:05:56 UTC
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.
Comment 7 Christian König 2014-07-25 09:56:17 UTC
(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.
Comment 8 Emil Velikov 2014-09-22 19:20:59 UTC
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/
Comment 9 Emil Velikov 2014-09-27 14:30:37 UTC
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 :\
Comment 10 Alexandre Demers 2014-09-27 21:46:35 UTC
Thanks for letting me know. I'll have a look at the result soon enough. ;)


bug/show.html.tmpl processed on Jan 16, 2017 at 21:50:17.
(provided by the Example extension).