librpmio, going back to bug #134362, exports a glob(3) implementation on its shared library that behaves differently from glibc's. It calls its own glob ... glob ... which can break programs if they link in -lrpmio. This affects every recent fedora and rhel. rpmio should have bundled a copy of the ancient glibc glob() under a different name, like rpmGlob. Or it could have stopped bundling when glibc's original symlink-related bug/behavior was changed. Or it can ensure that its glob is __attribute__((visibility,hidden)) from other compilation units. Or something. To reproduce e.g. on f16: % mkdir foo % cd foo % cat > foo.c #include <glob.h> #include <stdlib.h> #include <string.h> int main () { glob_t g; memset (&g, 0, sizeof (g)); int ret = glob ("./lib*/libc-*.so*", 0, NULL, &g); __builtin_printf ("%d %d\n", ret, g.gl_pathc); return 0; } ^D % ln -s /lib lib % ln -s /lib64 lib64 % ls ./lib*/libc-*.so* [... found files ...] % gcc foo.c % ./foo.c 0 2 <<---- ie libc found, all happy % gcc foo.c -lrpmio % ./foo.c 3 0 <<---- ie libc not found when searching through symlinks
Yup, blasts from the past... So is glibc glob() now returning dangling symlinks again? If so, when did it change?
(In reply to comment #1) > Yup, blasts from the past... > > So is glibc glob() now returning dangling symlinks again? If so, when did it > change? No it is not. #include <glob.h> #include <stdlib.h> #include <string.h> int main () { glob_t g; memset (&g, 0, sizeof (g)); int ret = glob ("*foo*", 0, NULL, &g); __builtin_printf ("%d %zu\n", ret, g.gl_pathc); return 0; } $ ln -s barfoobaz bazfoobar $ ./glob 3 0 Doesn't match, but $ ln -s /dev/null bazfoobaz 0 1 Does match. See http://sourceware.org/bugzilla/show_bug.cgi?id=866 But you might want to ask on the bug whether or not it may be reopened, the new glibc team has been revisiting old bug reports to see if any have been closed in error in the past. In any case, librpmio.so really should not export its own glob() implementation. It causes odd behaviour like for the testcase from the description where the rpm version of glob is broken (and that setup with /lib and /lib64 being symlinks is the default after usrmove in F17).
(In reply to comment #2) > (In reply to comment #1) > > Yup, blasts from the past... > > > > So is glibc glob() now returning dangling symlinks again? If so, when did it > > change? > > No it is not. Right. Would've been shocked to learn otherwise... > See http://sourceware.org/bugzilla/show_bug.cgi?id=866 > But you might want to ask on the bug whether or not it may be reopened, the new > glibc team has been revisiting old bug reports to see if any have been closed > in error in the past. Dunno if its worth the trouble. Even if the behavior got changed one of these days, rpm would still have to support versions with the current behavior for years to come. > In any case, librpmio.so really should not export its own glob() > implementation. No disagreement there, just perhaps mildly surprised to see somebody actually complain about it after all the years its been that way (I've known, intended to fix and forgotten about it at least five times by now :) I'd rather get rid of the internal implementation in the first place but...
BTW. Two different solutions to work around the broken glob in librpmio.so for programs linking against it: http://sourceware.org/bugzilla/show_bug.cgi?id=14078 The first allows librpmio to use its own glob, the second just overrides it with the one from glibc.
FWIW this has been fixed upstream git master now. For released rpm versions we'd probably want a bit less invasive fix though.
Fixed in rawhide now as of rpm >= 4.10.90
(In reply to Panu Matilainen from comment #1) > Yup, blasts from the past... > > So is glibc glob() now returning dangling symlinks again? If so, when did it > change? It changed in glibc 2.27 (Fedora 28), where this bug was fixed: https://sourceware.org/bugzilla/show_bug.cgi?id=866