Re: Bug#225449: wxwindows2.4: problems with ia64
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
Reply to: