On June 14, 2017 6:25:52 PM GMT+02:00, Joseph Myers <jos...@codesourcery.com> wrote: >On Wed, 14 Jun 2017, Richard Biener wrote: > >> The following patch makes sure we build the 32bit multilib libgcov >with >> large file support on x86_64-linux. libgcov.h ends up using >auto-host.h >> via including tconfig.h which is only valid for the main multilib >> (and on x86_64 doesn't need explicit large-file support defines). >That >> libgcc ends up using that is probably from times where it wasn't at >> the toplevel, some files already include auto-target.h generated by >> libgcc configure but most do so after including tsystem.h which is >> of course too late. I suppose libgcc files shouldn't include >tconfig.h >> from gcc/, but that's a change going to far for this bug ;) > >tconfig.h shouldn't include host-specific configure test results (as >the >relevant bits of config.in should be conditioned on USED_FOR_TARGET), >though that doesn't mean everything is indeed properly conditioned (and > >ideally we'd avoid configuration information from the gcc/ directory >needing to be used in target libraries at all).
But it seems it assumes that the results are independent on the multilib variant which is exactly the problem here - the main multilib not needing _FILE_OFFSET_BITS=32 while the 32bit one does. >> Other than libgcov libgomp, libcilkrts, libmpx and libstdc++ >> are similarly affected (they use fopen on the 32bit multilib) >> but not fixed. libubsan, libasan, libssp, libbacktrace and >libgfortran >> use open. While libgfortran configury has AC_SYS_LARGEFILE, the >> open use leaks in through libbacktrace (ubsan/asan might have the >> same issue, didn't investigate). libbacktrace lacks >AC_SYS_LARGEFILE. > >In general, watch out for off_t etc. as part of the ABI for such >libraries >(in which case AC_SYS_LARGEFILE could break the ABI). And if the code >uses fseek/ftell, it needs to change to fseeko/ftello (where available) >to >handle large offsets. True. Large files should be the very exception though. Richard.
