Previously David N. Welton wrote:
> It wouldn't cause problems if you did stat64(&foo) where foo is a
> regular 'struct stat'?
You never do stat64 yourself, if you enable LFS with the right options
that is all done transparently in libc.
Wichert.
--
___
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously David N. Welton wrote:
> > Right, so how do we fix this? It is our problem, in that we need
> > to make the software we distribute work together. But are you
> > also saying that upstream shouldn't be setting that bit in their
> > header
On Mon, Jan 07, 2002 at 01:20:45AM +0100, Wichert Akkerman wrote:
> Previously David N. Welton wrote:
> > Right, so how do we fix this? It is our problem, in that we need to
> > make the software we distribute work together. But are you also
> > saying that upstream shouldn't be setting that bit
Previously David N. Welton wrote:
> Right, so how do we fix this? It is our problem, in that we need to
> make the software we distribute work together. But are you also
> saying that upstream shouldn't be setting that bit in their header
> file?
As long as the API (and ABI) never exports things
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> > The Problem here is, that some header files define the LFS. This
> > should not be done.
> Indeed, doing that is broken behaviour.
Grepping about on my system, I see that mysql does it too, in
my_config.h:
#define _FILE_OFFSET_BITS 64
> > One go
Previously Bernd Eckenfels wrote:
> Yes, Wickert should reread your initial message.
Pleas spell my name correctly.
> The Problem here is, that some header files define the LFS. This
> should not be done.
Indeed, doing that is broken behaviour.
> One good Idea would be to include the define in
In message <[EMAIL PROTECTED]>, Wichert Akkerman writes:
>Bogus, if you compile them with the same options then will the the
>same. If you compile one with LFS and one without you can expect
>problems as you have demonstrated.
Well, yeah, but it seems dubious at best for Apache to be defining
_FI
On Sun, Jan 06, 2002 at 11:10:13PM +0100, David N. Welton wrote:
> In any case, changing the order of two header files doesn't seem
> offhand like the sort of thing that would go about changing the system
> definitions. That's poor modularity, in my opinion, because neither
> Apache nor Python, Tc
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously David N. Welton wrote:
> > I don't think it's right that two pieces of software can declare
> > the same struct and have them come out different things... there's
> > something wrong.
> Bogus, if you compile them with the same options th
Previously David N. Welton wrote:
> I don't think it's right that two pieces of software can declare the
> same struct and have them come out different things... there's
> something wrong.
Bogus, if you compile them with the same options then will the the
same. If you compile one with LFS and one
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously David N. Welton wrote:
> > I'm not sure exactly what problems this may cause, but I don't
> > like the looks of it... Interestingly (... or not) enough, that
> > define isn't created when building locally (version 1.3.23-dev)...
> It do
Previously David N. Welton wrote:
> I'm not sure exactly what problems this may cause, but I don't like
> the looks of it... Interestingly (... or not) enough, that define
> isn't created when building locally (version 1.3.23-dev)...
It doesn't cause any problems at all, it is by design.
Wichert
FILE 1
#include "httpd.h"
#include
int main() {
struct stat foo;
printf("size of stat __pad1 is %d\n", sizeof(foo.__pad1));
}
FILE 2
#include
#include "httpd.h"
int main() {
struct stat foo;
printf("size of stat __pad1 is %d\n", sizeof(foo.__pad1));
}
These produce differen
13 matches
Mail list logo
