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 ... cheers, Ron
