I'm an OS refugee converting a few 68k Macs to NetBSD 1.6. All the basic 
installs went cleanly, I built Xmac68k_color and it works, and I've been 
building some standard NetBSD packages, all of which had allowed me to 
sleep at the wheel. My 660AV had been cranking away fine for the past week 
on x11/kde3 until it hit kdelibs3.

The first problem I noticed was that the kdelibs3 configure script simply 
refuses to recognize that I have the CUPS package installed. First 
config.log complained that there was no -lcups lib, even though it was in 
/usr/local/lib. So I short circuited that and it next complained that the 
header cups/cups.h wasn't there, in spite of it being in 
/usr/local/include. Even config.log shows all the correct paths (especially 
/usr/local/include & lib) are being handed off to cc.

This was baffling so I manually ran the conftest.c codes from configure 
using the cc command line as pasted from the log. Both had no problem 
outside the script. I even dumped out the env and some other debug to make 
sure I had replicated the evals properly. Always worked fine outside but 
not inside the script. I wasted so much time that I finally hardcoded the 
CUPS results and at least things proceeded. Other configure checks seem to 
work before and after the CUPS checks and I didn't notice anything that 
would inherently cause the CUPS checks to fail. There are a lot on env vars.

So the kdelibs3 make started off with dcop. Things were looking great until 
the link, when the alarm bells went off when libtool started looking to 
build libDCOP.la:

*** Warning: linker path does not have real file for library -lgcc_pic.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgcc_pic and none of the candidates passed a file format test
*** using a regex pattern. Last file checked: /usr/lib/libgcc_pic.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Of course anything that used DCOP afterwards (almost all) whined similarly, 
as I developed a sinking feeling that all the KDE shared libs were turning 
into statics, which was going to blow all my feeble memory away at runtime, 
even if this build ever worked.

I started tracing back the dependencies to libgcc_pic.a and they seemed 
legit. Not being a NetBSD geek, I wondered why this lib wasn't built as 
shared, until I went in with nm and found out it was. The mail archives 
hinted at the sordid history of libgcc_pic.a and suggested the NetBSD 
libtool was tweaked to identify lib*_pic.a as shared. I realized that 
kdelibs3 was probably using its own libtool, so I slipped in the NetBSD 
version, which seems to cure the gcc_pic problem. I'm not sure I agree with 
the lib*_pic.a philosophy, but either way kdelibs3 has a problem.

I got pkgsrc with sup on 5 October and the only non-default selection I 
made was to use /usr/local instead of /usr/pkg (I really tried to make it 
work, but after hacking away for hours on some non-NetBSD package config 
and make files, I threw in the towel). I use tcsh and also set unlimit 
datasize, but I can't say if these have any effect.

I'm able to work around these problems, but being a newcomer, I can't be 
certain that they are not self-induced. Either way I would like to 
understand so the appropriate action can be taken. My gut feels like the 
CUPS problem could be 68k specific, but I don't think libtool is. If I'm on 
the wrong list, please let me know.

Cheers,
Mark