Re: off_t problems on ia64 again
On Tue, Mar 23, 2004 at 02:40:09AM +0000, Matthew Wilcox wrote:
> On Tue, Mar 23, 2004 at 12:22:54PM +1100, Ron wrote:
> >
> > Hi,
> >
> > Bug #239401 seems to show that we have problems with an inconsistency
> > in how off_t is defined on ia64 buildd's again.
> >
> > The last time this occurred there was some discussion on this list
> > about it, but we never arrived at any conclusive cause (except the
> > original submitter could fix the problem by recompiling everything
> > on the same machine).
>
> As I recall, the problem was due to wxwindows defining off_t itself.
> They didn't fix that yet?
I guess you didn't see my followup to that then. Your analysis assumed
wx was relying on the system to define __UNIX__, but that is not
correct. wx defines it itself in configure and includes it via the
generated setup.h
If this is failing I don't see where or how. Nobody responded again last
time so I assumed Torsten found a problem in audacity or the buildd's
and fixed it there.
I've attached my original reply in any case, if anyone has any other clues
about where this goes wrong I'd be very grateful to hear them.
I do somewhat wonder if something changed on the ia64 buildd's since wx was
last uploaded that means we just need to feed the wx packages through them
again.
thanks,
Ron
On Fri, Jan 02, 2004 at 04:30:11PM +0000, Matthew Wilcox wrote:
> On Fri, Jan 02, 2004 at 04:53:30PM +0000, Torsten Werner wrote:
> > On 2004-01-02, Matthew Wilcox wrote:
> > > I would say that audacity should be compiled with LFS support too.
> > > Suppose on x86 it attempts to deal with a file sized more than 2GB?
> >
> > The binaries are correct on x86 because the sources are using the opaque
> > type off_t.
>
> Now that I look into it, wxwindows is the culprit because the idiots
> define off_t *themselves*! Look at /usr/include/wx/filefn.h :
Nope, that's not it either.. though you are quite correct about it being
convoluted :-)
> // define off_t
> #if !defined(__WXMAC__) || defined(__UNIX__)
> #include <sys/types.h>
> #else
> typedef long off_t;
> #endif
>
> $ touch foo.c
> $ gcc -E -dM foo.c |grep UNIX
>
> gcc doesn't define __UNIX__ so they do a typedef. Oops.
The need for __UNIX__ is detected in the wx configure script and
it is exported to source via /usr/lib/wx/include/.../setup.h
filefn.h includes that (indirectly) through list.h
It may be possible that the configure script failed silently somehow
on the ia64 buildd, but that still doesn't really explain why it worked
ok for Torsten when he rebuilt it from the same source unless something
else has changed there in the meantime.
Torsten could you compare the last buildd logs to your own...
(the configure phase especially)
The buildd environment defining off_t as long long seems to be the only
way it could have got that way in the library symbols. wx defaults to
defining it as long on platforms that don't provide it natively (since
they probably don't have long long or LFS either :-)
Unfortunately I'm not really very familiar with the nuances of the ia64
arch myself, so any guess I'd hazard at how this might have happened
would be, well, hazardous ...
Reply to: