[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 15:44 +0530, Arun Raghavan wrote:
> 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).

But aren't the original semantics bad? I don't see any good reason why
we would want to support more than one search path.

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

Just using .fail would generate unnecessary errors in the log, and it
would also cause the startup not to fail when a module exists but fails
to load. Peter's tryload-module suggestion would probably work, but I
don't see the need for adding complexity.

-- 
Tanu

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

  Powered by Linux