| 1 |
On Friday, September 16, 2011 12:01:43 Mike Frysinger wrote: |
| 2 |
> On Friday, September 16, 2011 10:06:07 Michał Górny wrote: |
| 3 |
> > But doesn't switching mean we're going to hit LFS PITA once again? |
| 4 |
> |
| 5 |
> LFS hasnt really been a pain in a long while. but it's something worth |
| 6 |
> raising on the x32 lists (which i'll do) since x32 has native 64bit support |
| 7 |
> (uint64_t == %rax). so there should be no need to have 32bit interfaces at |
| 8 |
> all for read funcs. |
| 9 |
|
| 10 |
actually, this is already done. in my libx32 libc.so.6, the 64bit ver is an |
| 11 |
alias to the 32bit ver. |
| 12 |
5790: 000cff00 210 FUNC WEAK DEFAULT 11 openat64 |
| 13 |
6755: 000cff00 210 FUNC WEAK DEFAULT 11 openat |
| 14 |
6055: 000d07c0 92 FUNC WEAK DEFAULT 11 creat |
| 15 |
6595: 000d07c0 92 FUNC WEAK DEFAULT 11 creat64 |
| 16 |
|
| 17 |
so no, there shouldnt be any LFS issues with x32. all file offsets are 64bit. |
| 18 |
|
| 19 |
granted, if code does something like "int x = lseek(fd, 0, SEEK_CUR)", it'll |
| 20 |
break. but that's irrelevant to x32 ... that's broken for all 32bit systems. |
| 21 |
-mike |
Archives