On Sat, 26 Apr 2008, Ian Kent wrote: > OK, but if you "rpmbuild --rebuild" the source rpm on does it then also > produce a debuginfo package?
Yes, the debuginfo package was produced, and I installed it. But even so, and with -g appended to their LOCAL_CFLAGS variable (and it was in fact used in the compilation), "nm" reports that /usr/sbin/automount has no symbols. Stripping was no-op-ed, and I couldn't see where they were removed. If you or Jeff Moyer have a suggestion how to build this thing with complete symbols, I'll bet the output would be a lot more useful. OK, thanks to the search feature of tkinfo: gcc -s means omit all debug symbols. I relinked by hand omitting -s and copied the resulting binary into place (fortunately our anti-hack mechanisms are not as extensive as I'd like :-) Now I'll re-do the test. It would be nice if SuSE's spec file / Makefile were conditionalized for an easy debug build. > > There is an update (autofs-5.0.2-30.2) in which the issue is a missing > > dependency, so no code change is involved. The included patches are: > > Patch0: autofs-5.0.2-add-krb5-include.patch > > Patch1: autofs-5.0.2-bad-proto-init.patch > > Patch2: autofs-5.0.2-add-missing-multi-support.patch > > Patch3: autofs-5.0.2-add-multi-nsswitch-lookup.patch > > mmm .... > > [EMAIL PROTECTED] done]$ wc -l patch_order-5.0.2 > 67 patch_order-5.0.2 > > and they've picked up only 4? The build service has an unofficial package of autofs-5.0.3 hosted by Matthias Koenig (their developer assigned to autofs). Would it help if I build and install that one (with symbols)? Or would you prefer to stick with just one version? The source URL is http://download.opensuse.org/repositories/home:/makoenig/openSUSE_10.3/src/autofs-5.0.3-6.1.src.rpm if you want to inspect what they're including. Mixing topics slightly... Once when I let the test script run for several hours and it got hung up on a lot of mount points, I then ran gdb on the main automount process. gdb started, attached to the process, but did not load any library symbols even though available and did not print a list of threads. I can think of two reasons for this: I screwed up, or one of the threads splattered nonfatally. I've been focused on the hung client threads, but I'm starting to suspect that the "failed" mounts are equally an issue, because they happen in clusters on a single server (i.e. a single submount). "Failed" means that the process which reads the mountpoint directory finishes having read zero entries. I need to encode a possible error code, such as ENOENT, in the process' return code, so the main process can record and report something useful beyond just "failed". James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: [EMAIL PROTECTED] http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
