Re: [Simulavr-devel] More trouble with new auto* infrastructure

[William Rivet]

I went by what I got on my system. Not "right" I know.

I still want to check that it looks like a libbfd was found that might
work...

Ok, my proposed correction:

1.) I'll make a change to allow the path to the library to be given and
used wherever it is. Then to locate the include file I'll just
use ../include/ to include bfd.h
2.) I'll look into perhaps using "whatever libbfd" is available from the
system

Now I get to the harder part. What kind of simplistic check can I make
during compile that a compatable libbfd has been found?  I would like
this to fail to compile if libbfd is not right and give the user hints
right away rather than make them wait for the full build to fail. 

Thanks again guys, I appreciate the feedback.

Bill


On Mon, 2008-01-21 at 15:47 +0100, Joerg Wunsch wrote:
> With the new build infrastructure, I now can't even get it to
> configure at all on a Linux machine where I previously at least
> got it to a point where I could run the simulavrxx binary (only
> the _simulavrxx.o failed due to the missing -fPIC options).
> 
> It seems the configure script now insists on seeing a libbfd.a which
> has got an elf32-avr.o file in it.  First, there should never really
> be a check for a .a file -- a .so file is supposed to be usable as
> well, and shipping the .so appears to be the default on many Linux
> systems.
> 
> Second, there's really no need in insisting on an *AVR specific* build
> of binutils, at least not under Linux.  I know, I start sounding like
> a broken record here, I mentioned that a couple of times ago.  At
> least under Linux, /any/ generic build of libbfd.a (i.e. the usual
> system-shipped version!) will do for the stuff that is needed here
> (reading an ELF file, extracting the section data out of it, and
> extracting the symbol table).  I once wondered about that already when
> AVaRICE required a libbfd, and that's what Ted Roth told me about it.
> 
> Again as mentioned before, there's only one difficulty here with
> 64-bit Linux versions, as they keep their system libraries in
> /usr/lib64 rather than /usr/lib, so in order to get simulavrxx to
> use the system's libbfd on those machines, the search should prefer
> /usr/lib64 over /usr/lib.
>