Re: preprocessor macro to identify binutils version?

[Fred Cooke <fred dot cooke at gmail dot com>]

I spent a long time looking for this too, and failed. If there is, I'd
like to know about it. Otherwise I'll likely add a hack to binutils
for my use that provides this. That doesn't solve the general case,
though.

It'd be nice if the CVS/Git ID/revision (replace with "tarball" or
similar if not in VCS) was included, and a detailed date stamp, too.
If these were introduced into core binutils people could at least make
use of this info into the future (which would be sufficient for my
purposes).

Regards,

Fred.

On Fri, Aug 2, 2013 at 9:42 PM, Burlen Loring <bloring@lbl.gov> wrote:
>
> On 08/02/2013 11:46 AM, Andrew Pinski wrote:
>>
>> On Fri, Aug 2, 2013 at 11:49 AM, Burlen Loring <bloring@lbl.gov> wrote:
>>>
>>> Hi All,
>>>
>>> This is my first binutils foray. I'm making use of libbfd to provide
>>> detailed stack trace in an app if it crashes. In testing I've found
>>> systems[*] with older binutils where bfd_find_nearest_line segv's. I'd like
>>> to configure my app to disable the stack trace feature on systems with the
>>> older binutils. Is there a preprocessor macro that can be used to idnetify
>>> the binutils release? if not what's the best way to determine the binutils
>>> version?
>>
>> Won't it be better to use libdwarf and not use bfd?
>> BFD is not designed to be used outside of binutils/gdb.  Any use
>> outside of it I consider it a bug.
>>
>>
> Andrew,
>
> That's fairly discouraging news. I was not aware of the intention to keep libbfd use internal to binutils/gdb. I will look into porting to libdwarf.  However, if there's a reliable way to identify binutils versions it would be helpful. I'd like to make use of this code during the port.
>
> Burlen
>
>