Sorry for the awkward subject line  :)

I tried to built the KDE stuff on my NetBSD/SPARC 1.4.1 system, and it fell
over somehere in kdebase (like kdebase/work/kdebase-1.1.1/kfm or something)
due to a multiply-defined symbol in the link of "kfm".  (This was with the
KDE packages that came stock with 1.4.1, btw)

Rather than fight that, I grabbed the KDE 1.1.2 packages from -current
and have been building those.  So far so good, but I noticed this ...

I updated the kde/kdebase/kdelibs packages to the -current 1.1.2 versions.
When I started to build in pkgsrc/x11/kde, it said it depended on
pkgsrc/misc/kdeutils-1.1.2.  I didn't notice that, so the misc/kdeutils
that existed was the kdeutils-1.1.1 package from stock 1.4.1.

The "make" noticed that there was a misc/kdeutils there, and proceeded to
cd to ../../misc/kdeutils and try to do a "make" in there.

But it never noticed or complained that the kdeutils in there was 1.1.1, not
the 1.1.2 that the parent kde-1.1.2 needed.  It just started unbundling/etc.
It seems like it was happy that the package was there, and didn't check to
see if it was the right version before proceeding ...

Surely this is a bug?  Has anyone noticed this before?

I killed the make and pulled down the kdeutils-1.1.2, so everything's fine,
but thought I should mention it ...

(This next question might be port-sparc specific; I dunno.)

On another note related to building KDE - I'm seeing a *lot* of link messages
of the following form when linking KDE apps during the build process:

ld: /usr/X11R6/lib/libkde<mumble>.a(k<mumble>.o): RRS text relocation at
0x10NNNN for "_<color name>"

where "libkde<mumble>.a" can be "libkdeui.a", "libkdecore.a", "libkfile.a",
and so on; "k<mumble>.o" can be "kfiledialog.o", "kapp.o", and so on; and
"_<color name>" is usually "_black", "_white", "_magenta", and so on.

Do I need to worry about this?  Will running the binaries fall flat on their
face when they access these symbols?  (etc.)

I'm afraid I'm a bit ignorant when it comes to "ld" - does this have anything
to do with PIC issues?  (I realize these are .a libraries, not .so's)

	- Greg