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: Thu, 03 Feb 2005 10:28:55 -0800
- Subject: Re: ld/emultempl/elf32.em trusts inode numbers even under Mingwin
- References: <NUTMEGL74TheTtwq8zj00000585@NUTMEG.CAM.ARTIMI.COM>
"Dave Korn" <dave.korn@artimi.com> writes:
>
> It wasn't clear from your initial post what system was the target
> here: you mentioned the cygming host, which can target either
> i686-pc-cygwin or i686-pc-mingw, and of course which 'stat' function
> you get depends on which one of those you choose.
>
> Assuming your customers are compiling under a cygming host, but
> using the "-mno-cygwin" switch to target mingw, the change to ||
> from && should do it.
Umm. I think we have terminology issues... let me be extremely
specific. I build toolchains with --build=i686-linux,
--host=i686-mingw32, --target=$CPU-vxworks (there are about six
choices for target CPU). I give the resulting binaries to the
customers, who use them to compile code for their embedded targets.
Cygwin is not involved at any stage of the process, nor does anyone
other than me generate binaries which run under Windows.
> 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.
zw