[patch bfd]: Add further support for x86_64 mingw

Kai Tietz Kai.Tietz@onevision.com
Wed Jan 23 12:35:00 GMT 2008


Brian Dessent wrote on 22.01.2008 16:23:41:

> Kai Tietz wrote:
> 
> > > Can't you just use the standard inttypes.h macros, e.g.
> > >
> > > #define sprintf_vma(s,x) sprintf (s, "%016" PRIx64, x)
> > 
> 
> > I could add the inttypes.h header into bfd-in.h, but this would mean 
to
> > inherit config, too. This I think isn't a good choice. So the other
> 
> I suppose that would pull in a new dependency where it previously didn't
> exist before.  I was thinking you could provide a default value of llx
> (et cetera) if it's not defined, but you'd still need to do a header
> check and I guess that's too much trouble.
> 
> > solution to prevent to much target specific '#ifdef'-clauses would be 
to
> > add to bfd-in.h an equivalent to the printf formatters in standard
> > inttypes.h, like BFD_PRIx64, BFD_PRIx32, ...? Otherwise it seems to be
> > better to live with target specific clauses. What is your opinion 
about
> > this?
> 
> Is _WIN32 really the right thing to predicate this on?  For example
> someone using Cygwin and also using the w32api directly (by #include
> <windows.h>) will have _WIN32 defined, but they aren't using MSVCRT and
> so I64x is wrong.  Admittedly this is probably not something that is
> likely to occur in bfd, and I know this is a common idiom, but why not
> conditionalize it on __MSVCRT__ instead?  MinGW gcc defines this as a
> builtin right next to _WIN32 but it is not overloaded with the meaning
> of "I'm using the Windows headers."

AFAIK doesn't cygwin define _WIN32. I checked current gcc sources and 
didn't saw it for cgywin, just for mingw32. The __MSVCRT__ would be an 
alternative, for sure. But isn't the macro _WIN32 just the API we use?

Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.



More information about the Binutils mailing list