Version: (using KDE Devel) Installed from: Compiled sources Through a discussion on alt.os.linux.mandrake, I had to notice that every library has a risk of being broken when using the system off_t type in its exported interfaces, including structures and function synopsis. The point comes from the fact that systems like linux and solaris are "largefile sensitive" - a -D_LARGEFILE_SOURCE will shift the "off_t" type from being a 32bit entity into a 64bit entity. This will make for a nice and pretty callframe mismatch. Grepping a bit through header files installed on my system it occurs to me that "kio/jobclasses.h" uses off_t and uses functions and structures with it. More worrying, I had to notice that the kde plugins are sometimes compiled as largefile (referring to some fopen64) while others are not (importing the fopen symbol instead). A autoconf'ed lib 'centric treatment of the topic is given in: http://article.gmane.org/gmane.comp.sysutils.autoconf.general/1893 Given the platform independence layer of kde, it should be easy to ensure that no exported call of any kdelibs uses off_t - with c++ namemangling it is atleast improbable to end up in a callframe-mismatch but class size difference might propagate into plugins. Furthermore, it might be good to ask for a general policy of compiling as largefile - every unix98 compatible system must have largefile support and linux 2.4 / glibc 2.2 should have no more bugs in this respect. cheers, -- guido http://ac-archive.sf.net
http://ac-archive.sf.net/largefile With a perl script that shows where off_t-mismatches are.
I guess this needs to be fixed asap
I've updated the "off_t in headers" description. http://ac-archive.sf.net/largefile/off_t_headers.html The last (fine-print) paragraph does say this: One thing that I do not want to announce all too loud: if you find an improper usage of off_t in an older project, then you can add a quick hack by redefining those functions/structures to use int64_t instead of off_t. This will make structure-mismatch and callframe-mismatch problems to go away - but the seek problems will still exist and they might even hit you harder later since you've covered the usage of seek-offsets in a generic type instead of its dedicated off_t type, and basically forgot about to fix the problem for real. Therefore, if you did not add proper ifdefs to defend against improper usage in largefile-sensitive systems then better make a library typedef like `typedef int64_t mylib_off_t`. A later generation of that software may add proper check routines around this symbol. (remember: UNIX98 systems are _required_ to provide 64bit LFS).
Fixed for KDE 3.2