Okay. I restored the .h file and kept the mod in the cpp file. I tried building with that setup. Results were the same --- a failed build after about 20 minutes. I don't know if that result will change by moving to a virtual machine environment with 3.5.10 not installed. I will try that next! I'll keep testing as my schedule allows the next few days but I know I won't be able to provide much attention thereafter for a few weeks. I should be able to putter and tinker a little bit during that time, so any bugs we resolve now will help much the next few weeks.

No such package is installed in Slackware. There is a kerberos (krb5) package available in the slackbuilds repository. I could build the package and send you a package listing, but krb5 is not a requirement in Slackware. Let me know what you need.

When building arts in my new build environment I notice the following messages when building. I don't know whether the messages are harmless or meaningful. (repeats several times with different line numbers) ltdl.c: In function 'sys_dl_open': ltdl.c:605: warning: unused parameter 'loader_data' (repeats many times with different line numbers) gslmath.c:1005: warning: suggest explicit braces to avoid ambiguous 'else' (repeats many times with different line numbers) gsloscillator-aux.c:37: warning: unused parameter 'ifreq' gsloscillator-aux.c:38: warning: unused parameter 'mod_in' gsloscillator-aux.c:39: warning: unused parameter 'sync_in' gsloscillator-aux.c:40: warning: unused parameter 'pwm_in' (repeats several times) libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libstdc++.la' seems to be moved (the file exists at /usr/lib/libstdc++.la so I don't know what is checking in that directory.) The package compiles and the package size seems reasonable. Package contents are the same as the original stock 3.5.10 package. Darrell

The kdelibs sources were modified to avoid compile errors when the --disable-dnssd option is used and avahi is not installed. In the stock Slackware build script that option is not used. The stock Slackware build script compiles without those errors. In configure --help, the default option is not explicitly declared. Only the --disable-dnssd option is mentioned in the help output. There is no --enable-dnssd option mentioned in the --help options. I think the latter option is valid, however. In the stock configure there is a test for --enable-dnssd. One way or another, I presume that dnssd support is enabled by default. To the best of my knowledge Slackware does not include any kind of dnssd service. So an obvious question is why does the Slackware build script not fail? The stock configure file contains the following mild warning: if test "$have_libdns_sd" = "no"; then echo "" echo "You're missing Apple mDNSResponder 85 or later, therefore" echo "dnssd will be compiled as stub, without any real functionality." echo "If you want zeroconf support (www.zeroconf.org), you should install mDNSResponder first." echo "See dnssd/INSTALL for details." echo "" all_tests=bad fi I think this warning is the same as Trinity KDE. Yet the stock KDE 3.5.10 builds without halting if no such service is installed while the Trinity version does not. Based upon that warning, kdelibs should compile with or without the --disable-dnssd option and the KDE DNS-SD watcher service should compile as an unfunctional stub. At this point I don't think being required to use the --disable-dnssd option is the correct approach. Related to this issue, what will happen if I compile kdelibs with avahi installed, but an end-user installs that package without avahi installed? Will KDE choke or spew forth a bunch of error messages? As we have not yet ironed out the bugs that will allow me to install these recompiled packages, I have no idea of the result. I can see the KDE DNS-SD watcher service in the my stock version of the Control Center. Hopefully compiling with avahi but installing without causes no problems and the KDE watcher services just shrugs, so to speak. I can add some verbosity in the build script explaining that building with avahi installed is a good idea but installing the kdelibs package does not require having avahi installed. I doubt the Slackware maintainer compiled kdelibs with avahi installed. He's not that kind of person. His philosophy is to provide a basic operating system. If an end-user wants DNS-SD suppor then that would be up to the end-user. Therefore I think kdelibs should compile without needing the --disable-dns option or having avahi installed. I have all the original stock KDE 3.5.10 sources. Please let me know what information to forward to better resolve this issue. I can send anything from the stock Slackware build process too. Thanks. Darrell

I believe that is the default; if you want to verify that search in kdelibs or kdebase for the mouse cursor control code. That is the Ubuntu system default, not a Trinity default. Trinity honors the system wide settings unless specifically told to override them by the end user. Not sure OTOH. I believe the kpersonalizer code is in kdebase. Look for the mouse configuration module in kdebase/kcontrol and change the default value in the appropriate configuration template file (*.kcfg).

Ah, okay. My mind is/was stuck in thinking like the default Slackware and not the default Trinity. For whatever reason, the default with the original stock 3.5.10 must have been off by default. I'll add some comments in the build script so users understand the change and need for the option.

I sent the build log in a previous message. As a comparison test, I built the kdelibs package with the stock 3.5.10 and there were no messages about -lgssapi_krb5. Thus something has changed since then. :) I searched the kdelibs sources and found only two files using the lgssapi_krb5 term: kdelibs/kioslave/http/configure.in.in: GSSAPI_LIBS="${GSSAPI_LIBS}-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err ${LIBRESOLV}" kdelibs/kioslave/http/Makefile.am:kio_http_la_LDFLAGS = $(all_libraries) $(GSSAPI_RPATH) -module $(KDE_PLUGIN) -lgssapi_krb5 The kdelibs/kioslave/http/configure.in.in files in svn and 3.5.10 are identical. I looked at the two configure files but found nothing obvious why the svn version requires krb5. The configure --help output mentions a --with-gssapi= option, but I found no clue as to which option to pass to disable that support. I tried NOTFOUND but that did not work. Hopefully this information helps you!