This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld/emultempl/elf32.em trusts inode numbers even under Mingwin


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]