On Fri, 6 Jul 2001, Christoph Egger wrote:

> On Thu, 5 Jul 2001, Brian S. Julin wrote:
> 
> > On Fri, 6 Jul 2001, Christoph Egger wrote:
> > > I have looked roughly through Thayne's libtool patch for libgii.
> > > 
> > > The update to libtool 1.4 fixes our linking problem with libgg and,
> > > moreover, it adds support for the IA64 architecture. So we should be
> > > able to get GGI working on the Itamium platform. That's great!
> > 
> > It fixes the libgg problem here -- but note to Thayne to back out 
> > Cristophs quick fix in gii/Makefile.am
> 
> I just did that in CVS.
>  
> > However, I still have ${exec_prefix} in libgii.conf and the fatal
> > error - could not load ${prefix}/etc/ggi/libgii.conf thing going
> > on here.
> 
> These two issues must be solved before release, too.
> 
> The reason:
> 
> Each lib (libgii, libggi, libgalloc, etc.) has compiled in the
> location of its conf-file. The error
> "${prefix}/etc/ggi/libgii.conf" means, that the compiled in path is
> 
>       ${prefix}/etc/ggi/libgii.conf
> 
> which is obviously to fail when open it. So we must either parse
> ${prefix} in libgg somehow or we must fix configure.in to replace
> $sysconfdir, which holds ${$prefix}.
> 
> But when we go the second way, then we araise the original confdir
> problem again.
> 
> 
> The other issue to solve is the "${exec_prefix}" pattern in the
> conf-file. Having this pattern in it let all dlopen() calls fail in
> the way as fopen() fails with the ${prefix} pattern above.
> 
> So we have to parse it in libgg or we must fix that in configure.in.
> 
> In libggi.conf we must also fix the ${prefix} problem, so that the
> .include <path-to-fbdev.conf>/fbdev.conf  line doesn't fail, too
> (breakes fbdev in the matter of not loading the accelerated drivers).


Another solution is to go back to the original configure.in, where we
didn't have the ${prefix} problem and force the package maker to
determine the install-path _before_ compilation, so that $sysconfdir
wouldn't be changed.

Perhaps we should provide a script, which asks the package makers,
which install path he wants to use (of course it should suggest the
default path). Then the script automatically does the building
process and generates the package.


IMO this script is _no_ show-stopper for the 2beta4 release, but for
the final release.


CU,

Christoph Egger
E-Mail: [EMAIL PROTECTED]

Reply via email to