[Top][All Lists]
[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. ;-)
- [Simulavr-devel] More trouble with new auto* infrastructure,
Joerg Wunsch <=