https://bugzilla.novell.com/show_bug.cgi?id=460560 User kasievers@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=460560#c1 Kay Sievers changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |werner@novell.com --- Comment #1 from Kay Sievers 2008-12-19 07:41:02 MST --- Libreadline's code does not cope properly with getdents() behavior, so it must be fixed, or to work around it, it should just use _FILE_OFFSET_BITS=64 on 32 bit platforms, to prevent failures on some filesystems. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=460560 User kasievers@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=460560#c3 --- Comment #3 from Kay Sievers 2008-12-19 08:06:16 MST --- Read this and see why libreadline is broken on openSUSE: http://sourceware.org/ml/libc-alpha/2001-01/msg00216.html Thanks! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=460560 User devzero@web.de added comment https://bugzilla.novell.com/show_bug.cgi?id=460560#c5 --- Comment #5 from roland kletzing 2008-12-19 16:25:54 MST --- btw, here is some nice,comprehensive documents about LFS: http://www.suse.de/~aj/linux_lfs.html http://freshmeat.net/articles/view/709/ some excerpt from the latter one: -snip- Mixing it up Most of the software problems arise on the side of "small"file applications. Generally, one should compile all software as largefile as soon as the system provides these interfaces. This is pretty easy; AC_SYS_LARGEFILE in autoconfed software can do it, or just some _LARGEFILE_SOURCE to be defined somewhere. A lot of software, however, is not aware of a need to enable largefile mode somewhere. Hundreds of Open Source applications are compiled with 32bit off_t by default. It's simply been forgotten, and it would take a lot of work and publicity to make everyone aware, with the only result that the next new developer would miss it again. Because of this, we should use technical support tools to track the problem area of mixing compiled code from sides which support largefile and those which do not yet do so. -snip- The distro problem When the script is run on /usr/lib/*.so (or just /usr/bin) on a contemporary Linux system, it detects a lot of largefile mismatches. The common user will not experience any problems with that, so long as no file being handled is larger than two gigabytes. (Note that Unix98 mandates that base utilities like "cat" and "cp" be compiled with largefile support.) Open Source OS distributions, however, carry a lot of code from many different sources. In particular, there are several graphical frontends of the filemanager type which are not compiled in largefile mode. Sooner or later, the problem will come up. It would be best if no rpm/deb/whatever binary package has a largefile mismatch in the first place. This can be done if packagers and distro makers check binary packages while making them. It would be easy to integrate the checking routine into the set of post-%files tools (as they are called in RPM), which need to check the libraries and binaries anyway for dependent libraries (and do a "chrpath" on them, since they have been relinked in the DESTDIR staging area). The future The future should see all packages compiled in largefile mode, eliminating any problems with mixing libraries from different sides. A distro maker can ensure that, and if it means a few patches, that's good, since it makes the software more portable to FreeBSD/Darwin. At some point, one should really think about dropping the 32bit off_t default altogether, as was done with FreeBSD. Linux 2.4 and glibc 2.2 should be ready for this the step, leaving the days of "small"files behind. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=460560 Cyril Hrubis changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Basesystem AssignedTo|bnc-team-screening@forge.pr |mls@novell.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=460560 User mls@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=460560#c8 Michael Schröder changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@novell.com, | |mls@novell.com AssignedTo|mls@novell.com |coolo@novell.com --- Comment #8 from Michael Schröder 2009-02-27 09:13:59 MST --- Uh, that's not something I can decide as it breaks the ABI. Reassigned to coolo for now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=460560 User coolo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=460560#c10 --- Comment #10 from Stephan Kulow 2009-03-03 06:06:00 MST --- BTW: this is the script that Matz used to detect the problem - will only work on i586 of course. readelf -sW $1 2>/dev/null | egrep '^File| UND _?_?x?(stat|readdir)@' | sed -ne '/^File/h' -e '/^ /{x;p;x;p}' -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.