RE: Advise on long types in 64-bit binutils PE compiles.

[Jerker BÃck <jerker dot back at telia dot com>]

Thanks Ian,
I fully agree on your view of this issue. I just wished it would be a common conception.

> BFD never uses host types such as long when describing the external
> view of a structure in an object file.  It uses char arrays of the
> proper size.  See include/coff/pe.h.  These values are then swapped
> in and out of internal arrays.  The internal arrays may use host 
> types such as long; as mentioned above long may only be used if the 
> value is known to be 32 bits or less.

That is just it - can I trust binutils to treat the variable right even if I have a 64-bit long? Or should I change the type to int32_t to be sure (which is tempting). As I can shift from LP64 to LLP64 and back again for different compiles, I can confirm there is actually a difference. Exactly what is yet to be discovered, since current binutils are not functional in Interix. There is an old Interix-specific gcc-3.3 branch that is used, 32bit only. The binutils part is important since it's used to produce unix style shared libraries regardless of compiler. Without functional 64bits tools we are unable to use shared libraries, only static. So it's a porting attempt I'm doing.

If I understand you right, I can count on that 64-bit binutils do not need a 64-bit long type to be functional. If there are any parts that do, they should be considered as bugs, right? It would be nice if this could be confirmed. I can then use the LLP64 model (same as x86_64 mingw) as the basic porting platform. 

I wonder if anyone have successfully created 64-bit PE cross tools on a 64-bit unix system?

Jerker