[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkgsrc and XAPPLRESDIR
> > > However, I thought of what might be a better way... is there an Xt
> > > call that can load an app-defaults file such that the resources get
> > > handled with the right search priority? Because if so, we can probably
> > > solve the whole problem with some shared library hacks.
> > I'm not sure if I see your point, but isn't that what PR/26357 claims?
> No. The PR has a patch to hack libXt to add the app-defaults dir in
> /usr/pkg to the default app-defaults path. There are a bunch of
> reasons (most of them outlined near the top of the PR) why that's a
> What I'm talking about is arranging for xpkgwedge-compiled packages to
> call into libXt to add the pkgsrc app-defaults directory to the
> app-defaults search path dynamically, or at least add it to some
> suitable search path for Xt resources. The problem is that the lookup
> order for Xt resources is complex and fragile and if you insert the
> program's app-defaults file into the wrong place in it things will
> break. So I was asking if any suitable libXt call exists.
> If one does, this method will work on any ELF platform for any
> $PREFIX; if we have to add one it'll only work with NetBSD's native X
> and pkgsrc X, which is much less desirable but still better than
> nothing. But even then it'll at least adapt to the proper $PREFIX.
> (What I have in mind is to (ab)use the ELF dynamic linker's "wrap"
> feature to intercept XtAppInitialize.)
> My inclination remains to go ahead and patch the 108 packages though.
> Most of them also use imake and that too should be ripped out.
Well, then what's your conclusion?
You have an idea, but no code?
PR/26357 is unacceptable even for interim fix and
we should just add MESSAGE files to 108 packages?
Main Index |
Thread Index |