simulavr-devel
[Top][All Lists]
Advanced

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

Re: [Simulavr-devel] Compiling Simulavr und Mac OS X


From: Mathias Kussinger
Subject: Re: [Simulavr-devel] Compiling Simulavr und Mac OS X
Date: Sun, 16 Feb 2014 18:15:54 +0100

Hi Thomas,

thanks for your fast response :-)

On 16.02.2014, at 17:08, ThomasK <address@hidden> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/simulavr-devel




reply via email to

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