This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld/emultempl/elf32.em trusts inode numbers even under Mingwin
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "Dave Korn" <dave dot korn at artimi dot com>
- Cc: "'Binutils Mailing List'" <binutils at sources dot redhat dot com>
- Date: Tue, 08 Feb 2005 12:19:03 -0800
- Subject: Re: ld/emultempl/elf32.em trusts inode numbers even under Mingwin
- References: <NUTMEGCIdqJKBRYzuPu0000058f@NUTMEG.CAM.ARTIMI.COM>
"Dave Korn" <dave.korn@artimi.com> writes:
>> > It looks to me that mingw sets the st_dev field to the index of the
>> > DOS drive letter (excluding any skipped devices, so on my PC, A=1,
>> > C=2, etc...) and sets the st_ino to zero.
>>
>> Okay. That's mostly consistent with my observations, though I was
>> working out of Y: and I don't know why st_dev was zero... but there's
>> plenty weird about my Windows test box, so it could just be me.
>
> Yeh. What kind of drive is your Y:? SMB or NFS remote, perhaps?
> That might make a difference. Anyway, it seems like testing inode
> == 0 should be effective. Or just disable the optimisation
> altogether for mingw. I don't think there's any straightforward,
> quick, efficient way to tell if two files are the same in the
> general case.
It was indeed NFS remote. I agree, testing inode == 0 ought to be
adequate. Here's a revised patch.
zw
* emultempl/elf32.em (gld${EMULATION_NAME}_stat_needed):
Do not indicate a duplicate if st_ino is zero.
===================================================================
Index: ld/emultempl/elf32.em
--- ld/emultempl/elf32.em 3 Feb 2005 14:12:54 -0000 1.127
+++ ld/emultempl/elf32.em 8 Feb 2005 20:14:58 -0000
@@ -231,8 +231,16 @@ gld${EMULATION_NAME}_stat_needed (lang_i
return;
}
+ /* Some operating systems, e.g. Windows, do not provide a meaningful
+ st_ino; they always set it to zero. (Windows _does_ provide a
+ meaningful st_dev.) Do not indicate a duplicate library in that
+ case. While there is no guarantee that a system that provides
+ meaningful inode numbers will never set st_ino to zero, that
+ inode number is reserved by all Unix file systems in common use
+ (UFS, ext2, etc.) so we need not worry about that possibility. */
if (st.st_dev == global_stat.st_dev
- && st.st_ino == global_stat.st_ino)
+ && st.st_ino == global_stat.st_ino
+ && st.st_ino != 0)
{
global_found = TRUE;
return;