compile problems with xfrun
Brian J. Tarricone
bjt23 at cornell.edu
Thu Jul 22 17:53:34 CEST 2004
On Thu, 22 Jul 2004, edscott wrote:
> El jue, 22-07-2004 a las 08:44, Jasper Huijsmans escribió:
> > On Thu, Jul 22, 2004 at 08:05:39AM -0500, edscott wrote:
> > ...
> > > > Edscott, doesn't this create a build-time dependency that was only a run-time
> > > > dependency before?
> > >
> > > Uh-huh. In order to retain only run-time dependency only we would need a
> > > package for headers. Like the linux-headers package.
> > >
> > Hmm, I don't think I like the sound of that ;)
nor do i.
> Too late ;)
> > It does seem to me that it also makes libdbh a new dependency for Xfce
> > (instead of for xffm only). I'm not saying that is bad, but it is a change.
> No, that has not changed. I repeat: the modules code is not available at
> run time if libdbh is not found (modules depends on dbh). Xfutils checks
> for libdbh, but compilation will proceed if it is found or not. Libdbh
> cannot be loaded as a module for performance reasons.
i'm not sure i agree here. using g_module_open/g_module_symbol should
not impose a significant performance penalty beyond the setup time of
resolving your symbols. assuming you keep these symbols around
(stored in global function pointers, for example), there shouldn't be a
noticeable slowdown. using G_MODULE_BIND_LAZY will further increase
load time, although that may cause problems later if the user has a
broken installation. libdbh doesn't appear to have any deps beyond
libc, so i can't imagine it would be a problem.
either way, i don't see a problem with the current setup, where the
modules aren't loaded if libdbh isn't found at compile-time.
> > Anyway, I just wanted to raise the issue here to see if anyone has objections
> > or otherwise strong opinion about it.
so by that you mean you'll email the list and go ahead and do it anyway
before anyone has a chance to respond?
> Do you have any strong objection? Do you object to changing the location
> of header files for libxfcgui4 and libxfceutil as well? If so, why? I
> want to change the way xffm uses these libraries and do it in a
> load/unload fashion to keep memory footprint down.
are you saying you're planning on _moving_ the public headers for
libxfce4util and libxfcegui4 into xfce4/xfheaders? if so, then yes, i
have a problem with that. that's a real pain to maintain, and makes the
library build procedure problematic. i don't see why you can't just
load the libraries you need dynamically if you want to make them
optional. if you want the core xfce libs to be optional, you need to
make xffm work around that, not make the core libs work around you.
what you need to do is make a stub library that uses
g_module_open/g_module_symbol to load the symbols you need, and
statically link that into xffm. you can either keep a local copy of the
headers you need with xffm or xfce4-modules, or simply copy out the
declarations into your stub header and turn them into function pointers.
i'm sorry if that's a pain for you, as it would require you to keep up
with library changes, but you can't bend the world to your needs.
furthermore, i don't see why xfheaders is necessary. why can't
xfce4-modules simply install its own header files? i may be
misunderstanding exactly what you're trying to do here, but i'm sure
there's a less confusing way of doing this that avoids adding another
More information about the Xfce4-dev