Summary: | sys-libs/glibc-2.5-r1 fails to build complaining of undefined symbols getspnam etc. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Auty (RETIRED) <ikelos> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
FEATURES="-ccache" MAKEOPTS="-j1" LDFLAGS="" Emerge --info output
Gzipped build log |
Description
Mike Auty (RETIRED)
![]() Created attachment 114115 [details]
FEATURES="-ccache" MAKEOPTS="-j1" LDFLAGS="" Emerge --info output
those functions are supposed to be in libc.so itself, so if yours isnt providing it, you've got big problems :p post the output of: readelf -s /var/tmp/portage/sys-libs/glibc-2.5-r1/work/build-default-i686-pc-linux-gnu-nptl/libc.so.6 | egrep '[gs]etsp(nam|ent)' also, run `emerge glibc >& log` and post the log file as an attachment Created attachment 114211 [details]
Gzipped build log
It appears as though something must have changed on my system or that the glibc-2.5 patchset has been updated since I last built it in December, because now glibc-2.5 doesn't build either.
The egrep function didn't return any lines, so it appears libc.so.6 doesn't actually contain the missing symbols. I can attach the results of readelf -s if it will help?
Provided the requested file as an attachment. run the same readelf|egrep on these files: /var/tmp/portage/sys-libs/glibc-2.5-r1/work/build-default-i686-pc-linux-gnu-nptl/shadow/getspnam.o /var/tmp/portage/sys-libs/glibc-2.5-r1/work/build-default-i686-pc-linux-gnu-nptl/shadow/getspnam.os plasma shadow # readelf -s getspnam.o | egrep "[gs]etsp(nam|ent)" 1: 00000000 0 FILE LOCAL DEFAULT ABS getspnam.c 17: 00000000 260 FUNC GLOBAL DEFAULT 1 getspnam 19: 00000000 0 NOTYPE GLOBAL DEFAULT UND __getspnam_r plasma shadow # readelf -s getspnam.os | egrep "[gs]etsp(nam|ent)" 1: 00000000 0 FILE LOCAL DEFAULT ABS getspnam.c 21: 00000000 290 FUNC GLOBAL DEFAULT 2 getspnam 25: 00000000 0 NOTYPE GLOBAL DEFAULT UND __getspnam_r this is the problem: /bin/cat: hsadow/stamp.os: No such file or directory /bin/cat: hsadow/stamp.o: No such file or directory /bin/cat: hsadow/stamp.oS: No such file or directory this keeps the shadow/ objects from being integrated into libc.so the odd thing is that the cat command is given "shadow/..." is your shell/environment/coreutils sane or you been screwing with them ? Actually, that explains a whole lot. I'm very sorry to have inconvenienced you with this bug, given that it's my own fault. Mid-way through last year one of the pranksters in my office decided to wait until I walked away from my computer without locking it and then cat /etc/shadow (I guess that's what you get for working with penetration testers), so I set up a fake shadow file and wrote a wrapper for cat to do the letter transposition. It appears I shot myself in the foot, sorry! 5:( (In reply to comment #8) > Mid-way through last year one of the pranksters in my office decided to wait > until I walked away from my computer without locking it and then cat > /etc/shadow (I guess that's what you get for working with penetration testers), > so I set up a fake shadow file and wrote a wrapper for cat to do the letter > transposition. Yikes :/ That's pretty pointless - anyone really breaking in would do '/bin/cat /etc/shadow' or supply their own shell utilities anyway. A better approach in a potentially hostile environment is to _never_ open a shell as root, and use sudo for the few commands that need it (and _don't_ set sudo to skip the password requirement for your uid). This is probably what the prankster was trying to highlight to you... You would think it's pretty pointless, but the guy was a trainee and didn't actually know much about *nix: the history command showed him using just plain cat. Also, I hadn't deemed such a lame attack as a high risk in our office, go figure... |