Bugzilla – Bug 129434
Currently the libc function glob() is broken in BETA.
Last modified: 2005-11-08 14:24:17 UTC
In current BETA I get several time an error for the ksh: error: File not found by glob: /var/tmp/ksh-93q-build/usr/lib64/ast/*.so of rpm using glob to find the files in its files list. The file is a symbolic links which its self exist: g31:/ # ll -G /var/tmp/ksh-93q-build/usr/lib64/ast/*.so lrwxrwxrwx 1 abuild 24 Oct 19 16:21 /var/tmp/ksh-93q-build/usr/lib64/ast/libast.so -> /lib64/ast/libast.so.5.4 lrwxrwxrwx 1 abuild 24 Oct 19 16:21 /var/tmp/ksh-93q-build/usr/lib64/ast/libcmd.so -> /lib64/ast/libcmd.so.1.2 lrwxrwxrwx 1 abuild 24 Oct 19 16:21 /var/tmp/ksh-93q-build/usr/lib64/ast/libdll.so -> /lib64/ast/libdll.so.1.0 lrwxrwxrwx 1 abuild 26 Oct 19 16:21 /var/tmp/ksh-93q-build/usr/lib64/ast/libshell.so -> /lib64/ast/libshell.so.1.1 Not that using relative symbolic links does not help because those will be replaced by /usr/lib/rpm/brp-symlink with absolute symbolic links.
It's because there's a "ifarch none" around all the patches, including glibc-2.3.3-glob-revert-stale-symlinks.diff ...
No, it is because our RPM or spec files are broken according to some "wise" glibc guru. Michael, do you know how RedHat solves this problem with rpm? Our rpm should work with a plain glibc, too, and not depend on special, incompatible changes to the default behavior of glibc functions.
They probably point the glob "stat" function to "lstat". But I want to know what the standards say in this case. I can't believe glob() cannot return dangling symlinks. That would mean "rm sym*" could never delete a dangling symlink.
Hey, not fair. Don't assign this to me. Instead answer the question...
See: glibc glob change: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126460 rpm workaround: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134362 In other words: Uli Drepper again. Sigh.
The standard is pretty unclear in our opinion (but it seems not for this wise glibc guru). Our rm works fine with deleting dangling symlinks with "rm sym*". Red Hat has no glob patches on glibc or coreutils. But I have no idea how they solved the rpm problem.
They copied the old glob.c and fnmatch.c from the glibc into the rpm sources and use them. My point is I don't want to do this if glibc gets changed again in the near future... bash wisely doesn't use glibc's glob...
(In reply to comment #5) > In other words: Uli Drepper again. Sigh. I wrote "a wise glibc guru". Who else?
(In reply to comment #7) > They copied the old glob.c and fnmatch.c from the glibc into the rpm sources > and use them. > My point is I don't want to do this if glibc gets changed again in the near > future... The problem is: It is not trivial to revert Uli's changes. Since the compiler is fixed, the patches are currently enabled again. But with the next change from Uli to glob it could be that we have no real chance anymore to revert to the old behavior. Our current patch introduces an old bug for this and I'm only waiting for the next L3 call so that we have to remove the reverting patch. For that case we should be prepared with a working rpm.
I've patched rpm.