Hi Thomas,
thanks for your fast response :-)
On 16.02.2014, at 17:08, ThomasK <nongnu....@sce-gbr.de> wrote:
> Hi Mathias,
>
>> Mac Ports provides the tools glibtool and glibtoolize. I have attached a
>> diff for bootstrap to use these tools if available.
>
> Diff? Maybe the list software has removed the diff. Could you attach it as
> text?
It’s a simple hack:
18a19,27
> LIBTOOL=libtool
> LIBTOOLIZE=libtoolize
>
> if [ "`uname`" = "Darwin" ] && [ -n "`which glibtool`" ]
> then
> LIBTOOL=glibtool
> LIBTOOLIZE=glibtoolize
> fi
>
30c39
< (libtool --version) < /dev/null > /dev/null 2>&1 || {
---
> ($LIBTOOL --version) < /dev/null > /dev/null 2>&1 || {
32c41
< echo "You must have libtool installed to compile $PROJECT."
---
> echo "You must have $LIBTOOL installed to compile $PROJECT."
84c93
< libtoolize ${verbose} --copy --force
---
> $LIBTOOLIZE ${verbose} --copy --force
>
>> Second, simulavr requires libiberty, which is not recommended anymore and
>> difficult to obtain. At least on this Mac I can
>> remove libiberty from linking without getting any unresolved symbols. I
>> haven’t checked the other architectures. If it is no
>> longer required I’d suggest to remove it from the build process.
>
> It depends mostly on used distribution. Sometimes (maybe older linux
> distributions) have used it and you have got a linker error, if this wasn't
> available. So, sometimes it's necessary to have it, sometimes not. How do you
> removed it from linking? Editing makefile by hand? Or do you have patched
> ax_avr_environ.m4?
I recognize this because some of the AVR binaries come from a ready-to-use
bundle. They didn’t provide a 64bit version and libtool told me that it will
ignore it. And no missing symbols. I did then run tests by running the libtool
command line manually without libiberty, that went well.
>> /usr/local/avr/bin/simulavr -d atmega128 -F7372800 -W 0x91,- -a 0x92 -e 0x93
>> -f test-sim.elf
>>
>> FATAL: file avrreadelf.cpp: line 152: File 'test-sim.elf' isn't a elf object
>
> Looks so, that in your simulavr the used bfd lib doesn't recognize the elf
> file. Why? That's a good question. What bfd library is linked in? Maybe you
> have to declare the right bfd lib with the option --with-bfd=path in
> configure. (maybe it works, I know, that there sometimes problems with that
> and then you'll get crashes. So be careful. :-) Successful build does not
> mean, that it really works!)
I have tried different ones with libbfd from the tool bundle and from the
binutils provided by Mac Ports. They failed because of missing symbols or wrong
architecture.
The one I got to compile was a fresh binutils-2.24 compiled from scratch. This
one fails to read the elf file.
Does libbfd depend on —target? I get the same error with and without —target=avr
Thanks,
Mathias
> On my todo list is to replace the bfd library by using ElfIO, because it's
> also a problem on MinGW/Windows. But when ...
>
> cu, Thomas
>
> _______________________________________________
> Simulavr-devel mailing list
> Simulavr-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/simulavr-devel
_______________________________________________
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
