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: Paul Eggert
Subject: Re: ac-archive: ac_sys_largefile and libraries...
Date: Sat, 11 Jan 2003 09:25:56 -0800 (PST)

> Date: Sat, 11 Jan 2003 11:00:57 +0100
> From: Guido Draheim <address@hidden>

> > 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

Then fix your linker so that it also tells you about off_t linkage
screwups.  But don't contort every other tool in the toolchain to add
support for misconfigured programs.

> 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.

Yes, that's the only sane solution.  And it's the solution we should
be striving for.  We should not waste our time trying to support mixed
32- and 64-bit chimeras.

One good way to head in that direction is to make 64-bit off_t the
default, with 32-bit off_t available only by explicit request.  POSIX
allows this behavior, and I don't see why more people don't do it that
way these days.

> let the application maker call explicitly the func64
> symbols and off64_t type if that is supposed to be the intent.

No, no, that is a misguided approach.  Applications and libraries
should be written portably, and should work regardless of the width of
off_t.  Applications should work even if off_t is 128 bits.  It is a
mistake to hardwire off64_t, fseek64, etc., into applications and
libraries.  They are meant only for temporary conversions in
closed-source applications (e.g., you have a 32-bit 3rd-party library
that you can't recompile).  They have little real utility in the
open-source world.




reply via email to

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