simulavr-devel
[Top][All Lists]
Advanced

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

Re: [Simulavr-devel] Trouble building simulavrxx on Darwin


From: Klaus Rudolph
Subject: Re: [Simulavr-devel] Trouble building simulavrxx on Darwin
Date: Fri, 15 Oct 2004 08:08:01 +0200 (MEST)

Hi David,
> 
> The computer I am using for this development is a laptop, and travels 
> with me from home to work. At work, it is not hooked up to the 
> internet, and at home, the internet connection is behind a firewall 
> >from the ISP, so I think that this would be difficult or impossible.

That is a question of firewall configuration. If you could open a 
conection to my system we will also be able to handle this. 



> This was very helpful information. I looked for a system libc, and was 
> unable to find it!

I don´t know how you search, but if you have installed gcc correct you have
a libc. I´m shure! :-)

>Searching the web, I found that the functionality 
> was placed in libSystem.dylib. I tried linking this in manually to 
> solve the  missing _dcgettext problem, but it didn't help. Further 
> research revealed that libintl.a might have the missing _dcgettext, so 
> I tried linking that in as well. It worked! But I got other errors 
> about missing references in libiconv. I did a find to see where that 
> was, and then linked it in. First, I got an error about multiple 
> definitions, but by changing the order, I was able to get  it to 
> compile! The full compile command is as follows:
> 
> $ g++ -O2 -g -O2 -o .libs/simulavr main.o  -L../src/.libs  -lavrsim_pp 
> /Users/dtlinker/Desktop/AVR-GCC/binutils-2.15/bfd/libbfd.a  
> /libiberty.a /usr/lib/libiconv.dylib /usr/local/lib/libintl.a
> 
I´m a bit wondering about that. OK, if it works. But if Bill have to
prepare the build scripts for OS X we should not put there
a workaround. For that I please you to install a actual gcc (3.4.2)
to your system and remove the complete old stuff. 

After that we try to build some simple programs to be shure that all
the things are working correct. 


> It then hung on running swig:
> 
> creating simulavr
> swig -c++ -o simulavr_wrap.cpp simulavr.i
> make[2]: swig: Command not found
> make[2]: *** [simulavr_wrap.cpp] Error 127
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1

@Bill: No check for swig before using it? :-) I think we should!

> It ran, but with a lot of warnings:

The warnings are OK. They come from a very stupied swig file. I simply
include all what I need and there is more then swig could interpret or
wrap. Normaly the wrapped headers must have some preparations for swig but
this is not done actually. But this will not result into trouble only
in larger files :-) If swig runs and you have a simulavr_wrap.c?? all is ok.

> I then did another make, and it progress a lot further, ending with the 
> following messages:
> 
> g++ -I. simulavr_wrap.o application.o decoder_trace.o printable.o 
> at4433.o at8515.o at8515special.o atmega128.o avrdevice.o avrerror.o 
> avrmalloc.o decoder.o flash.o gdbserver.o hardware.o helper.o hwad.o 
> hwacomp.o hweeprom.o hwextirq.o hwmegaextirq.o hwmegatimer.o 
> hwmegatimer0123irq.o hwport.o hwspi.o hwsreg.o hwstack.o hwtimer.o 
> hwtimer01irq.o hwuart.o hwwado.o ioregs.o irqsystem.o keyboard.o lcd.o 
> memory.o mysocket.o net.o pin.o pinatport.o rwmem.o scope.o 
> systemclock.o trace.o ui.o -ltcl 
> /Users/dtlinker/Desktop/AVR-GCC/binutils-2.15/bfd/libbfd.a /libiberty.a 
> -lc -lm -lncurses -shared -o simulavr.so
> g++: unrecognized option `-shared'
> ld: Undefined symbols:
> _main
> _systemClock
> _dcgettext
> make[2]: *** [simulavr.so] Error 1
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1

The option -shared is for building shared libraries. This library could
be "load" into the tcl/tk shell (wish). If you gcc have no support for
-shared you will not be able to build shared libraries at all!
I think something is totally wrong with your gcc installation. 
OK. I think install gcc 3.4.2 and we will try all this again here.

But for now:
The other errors come from ignoring the -shared option. If you build a
shared library there is no need to have all symbols. And especially
main is not required because the program which uses the lib is "main" so no
main is required. I wonder that systemClock is missing and that 
would run into trouble I think. Have you the actual CVS content from
my simulavrxx project? If not, please take that. The tgz package is
outdated.




> 
> > Another question: Which gcc you use for compilation? We prefer >=3.4.1.
> >
> it is version 3.3 20030304
Please do an update!!! Please the complete compiler with all libs. I don´t
know
how gcc is working on OS X but I hope that there is no need for patches or 
some special libraries or so. But for this question please look in OS X
mailing lists, that is a problem which we could not solve here.



But at all:
If you have linked simulavrxx you could work with it. The missing
simulavrxx.so
is not needed for "normal" simulation, it is only used if you want to start
from a tcl/tk shell.(wish).
 
Please play around a bit with the simulator and tell us if it works.
Building (compile/link) is not all on building software, especially if
mistirious libraries come into the product :-) So run the simulation a bit
and
we will see:

compile a gcc programm with -g option that we could see debug infromation.
After that run simulator with:
simulavrxx -f a.out -tout.txt
If out.txt contains a lot of trace info all is ok i think. :-)))

If not, yes write a mail :-)


For all other compiler related problems please do the update. 
For build toolchain problems we need support from Bill, but he is on the way
I think.

Bye
   Klaus




-- 
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl





reply via email to

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