This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> Thorsten Kukuk writes: Th> On Thu, May 25, Ulrich Drepper wrote: >> Thorsten Kukuk <kukuk@suse.de> writes: >> >> > But with the current situation, I think we need to duplicate this >> > files for every big endian architecture and change the syscall. >> >> Yes, and this is no real problem. Just locate them and provide an >> alternative file. Assume we cannot change the kernel (which is most >> probably the correct assumption). Th> Ok, here is a patch for sparc32. It seems PowerPC doesn't support Th> LFS in the moment, but they have to make the same changes if they Th> support it. Have we more big-endian, 32bit architectures ? Th> The other syscalls looks ok. Th> The patch is for glibc 2.1 and 2.2. Th> 2000-05-26 Thorsten Kukuk <kukuk@suse.de> Th> Th> * sysdeps/unix/sysv/linux/sparc/sparc32/ftruncate64.c: New, change Th> syscall arguments for big-endian. Th> * sysdeps/unix/sysv/linux/sparc/sparc32/truncate64.c: Likewise. Th> I've one design question: In case of such problems do we put little endian or big endian files in sysdeps/unix/sysv/linux? Currently we have there for example: - ftruncate64 that works for little endian - pread64 that works for big endian Or should rewrite the general version to use: #if __BYTE_ORDER == __LITTLE_ENDIAN #elif __BYTE_ORDER == __BIG_ENDIAN #else #error "..." #endif Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |