[PATCH 1/2] daemon: Fix dlsearchpath while running from build tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2013-04-22 at 12:41 +0300, Tanu Kaskinen wrote:
[...]
> >                              *ifstate = access(pathname, F_OK) == 0 ? IFSTATE_TRUE : IFSTATE_FALSE;
> >                              pa_log_debug("Checking for existence of '%s': %s", pathname, *ifstate == IFSTATE_TRUE ? "success" : "failure");
> >  
> > +                            if (PA_UNLIKELY(pa_run_from_build_tree())) {
> > +                                /* If run from the build tree, search in <path>/.libs as well */
> > +                                char *ltpathname = pa_sprintf_malloc("%s" PA_PATH_SEP ".libs" PA_PATH_SEP "%s", p, filename);
> > +
> > +                                *ifstate = access(ltpathname, F_OK) == 0 ? IFSTATE_TRUE : IFSTATE_FALSE;
> > +                                pa_log_debug("Checking for existence of '%s': %s", ltpathname, *ifstate == IFSTATE_TRUE ? "success" : "failure");
> > +
> > +                                pa_xfree(ltpathname);
> > +                            }
> 
> Why do we search in two places if we're running from build tree? Why is
> this code so complicated anyway, looping over "multiple" paths, even
> though we will never have more than one module search path?

I tried to keep the original semantics (which is that dlsearchpath can
have multiple locations).

We could possibly put these in a .fail block instead and always try to
load, implementing the .tryload-module mechanism peter suggests.

-- Arun

-- Arun



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux