Subject: Package make not determining correct dependancies/RRS text relocations
To: None <tech-pkg@NetBSD.ORG>
From: Greg Earle <earle@isolar.DynDNS.ORG>
Date: 11/05/1999 18:12:30
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)