Re: kdeadmin - heimdal

[Christian Biere <christianbiere%gmx.de@localhost>]

Lieven De Keyzer wrote:
> On 12/7/06, Christian Biere <christianbiere%gmx.de@localhost> wrote:
> >Ond?ej T?ma wrote:
> >> Problem is, that hemidal config generate these CFLAGS:
> >> # krb5-config --cflags
> >> -I/usr/pkg/include/krb5 -I/usr/pkg/include
> >> instead of:
> >> -I/usr/pkg/include

This wouldn't really solve anything.

> >> and projects which are using hemidal could include it's headers via:
> >> #include <krb5/glob.h>
> >> #include <krb5/fnmatch.h>

This still doesn't help if you have /usr/include/krb5/.

> >> instead of:
> >> #include <glob.h>
> >> #include <fnmatch.h>
> >>
> >> But, problem is more disputable, cause these headers is in system too,
> >> but with some another extension for krb5 (heimdal) :S

I just see that <glob.h> and <fnmatch.h> are part of POSIX. So if something
includes those and expects being able to include local or project-specific
files with those names, they will lose anyway.

> >I think the only reasonable approach is to get rid of these headers
> >altogether. Either by using building in a chroot

> I'm not really familiar with chroot. Could you elaborate on this or
> exemplify how heimdal and kdeadmin should be built using chroot?

You would copy or hardlink all essential files from /usr/include and
/usr/lib into a sandbox arena, then chroot into it and do all pkgsrc
compiling in there.

> Are you talking about Slackware's glibc headers or the ones from heimdal?

I don't think there's any libc in pkgsrc, so you must not remove any
glibc headers or you'll hardly be able to compile anything. GCC might
be using sanitized cached copies of those though, not necessarily the
ones you see in /usr/include. For a couple libraries like libm, librt
and others there exist no replacement either. In general it's not
really a good idea to have the same library in pkgsrc and in the
base system, so I'd try to use as much as possible from pkgsrc.

-- 
Christian