simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joerg Wunsch
Subject: [Simulavr-devel] More trouble with new auto* infrastructure
Date: Mon, 21 Jan 2008 15:47:23 +0100
User-agent: Mutt/1.5.11

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.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]