autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ac-archive: ac_sys_largefile and libraries...


From: Guido Draheim
Subject: Re: ac-archive: ac_sys_largefile and libraries...
Date: Sat, 11 Jan 2003 11:00:57 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826

Paul Eggert schrieb:
Date: Mon, 06 Jan 2003 11:16:17 +0100
From: Guido Draheim <address@hidden>

The problem is in call-mismatch: the library is compiled as 64bit off_t
which makes a call like "lseek (int,off_t,int)" to be actually an
"lseek (int,off64_t,int)". When an application is compiled without the
largefile-macro,


Yes, that's the problem.  Don't mix 32-bit applications with 64-bit
libraries.  It's that simple.

Simple as that - it's a realworld problem. I have just submitted
a bug report to the zlib people (!!!!) as they are compiling their
library as 32bit off_t - and gzip itself gets compiled as a
largefile 64bit off_t application. Yes, and only by luck, they do
not use the gztell()/gzseek() pair which is affected.

$ objdump -T /usr/lib/libz.so | grep fopen
00000000      DF *UND*  00000099  GLIBC_2.1   fopen

$ objdump -T /usr/bin/gzip | grep open
08048c30      DF *UND*  0000003b  GLIBC_2.1   open64

$ grep off_t /usr/include/zconf.h /usr/include/zlib.h
/usr/include/zconf.h:#  include <sys/types.h> /* for off_t */
/usr/include/zconf.h:#  include <unistd.h>    /* for SEEK_* and off_t */
/usr/include/zconf.h:#  define z_off_t  off_t
/usr/include/zconf.h:#ifndef z_off_t
/usr/include/zconf.h:#  define  z_off_t long
/usr/include/zlib.h:ZEXTERN z_off_t ZEXPORT    gzseek OF((gzFile file,
/usr/include/zlib.h:                                  z_off_t offset, int 
whence));
/usr/include/zlib.h:ZEXTERN z_off_t ZEXPORT    gztell OF((gzFile file));


It's just like you shouldn't mix x86 applications with sparc
libraries.  They're different flavors of executable code.  Don't try
to link them together.

Well, the linker would tell you in this example - but it is a
little different with mixing libs/apps compiled for the same
system with the same compiler and the same compile-flags but
just with a different -Ddefine for off_t-size - the linker can
not know the difference, it does not even have _chance_ to
mark the libraries with different bits. They are just plain
identical (unless the library makers renames functions like
it is usually done, making up a gztell64/gzseek64 pair).



A library maker should therefore put in efforts to defend itself


I disagree.  Should an x86 library maker defend against being linked
to a sparc application?

wrong argument, see above.


Of course, I realize that one _can_ build mixed 32-and-64 bit apps --
just as one _can_ link x86 code to sparc code.  However, generally
speaking it's a bad idea, as it is much more trouble than it's worth.

That's an opinion - the problem is not whether we would like such
things to happen - they _are_ happening, and all I'm asking is for
means to "defend" oneself. That can be as simple as

#if defined LARGFILE_SENSITIVE && ! defined _LARGEFILE_SOURCE
#error using this library requires to enable largefile mode
#endif


I'll go even further and say that if you have an application that uses
file offsets and you don't invoke AC_SYS_LARGEFILE or its equivalent,
you're not serious about building portable code.  Apps that don't use
AC_SYS_LARGEFILE aren't worth worrying about.


Sometimes it's deeper - the application may simply be not aware that
some libraries make use of an off_t in their exported headers. For
example, I did just submit a bug report to the kde guys where such
thing exists in kio, and where I do also noticed that some plugins
are compiled 64bit-off_t while others are 32bit-off_t.

The end of the discussion can only be to change the compilation
behaviour globally - making 64bit off_t the default if that is
supported by the system, and dropping the settable off_t altogether.
So, if the system is not clean for 64bit off_t (like linux before
2.4 and glibc before 2.2) then do not allow a global redefine for
off_t, and let the application maker call explicitly the func64
symbols and off64_t type if that is supposed to be the intent.

Yes, I am aware that there might be compatibilty problems with
binary-only software, but that is only an administrative task.
The deeper problem is for the casual opensource programmers who
might simply be not aware of the problems he might run in when picking
up off_t _anywhere_ in the public headeras, it is quite probably that
he did never hear of  largefile linking problems, and to strengthen
this opinion, see the http://bugs.kde.org/show_bug.cgi?id=52843
that gets  assigned to stephan kulow himself which I would regard
as a very experienced programmer - and it still crept in.

cheers, guido                               http://ac-archive.sf.net






reply via email to

[Prev in Thread] Current Thread [Next in Thread]