RE: [avr-gcc-list] Building AVARICE on Cygwin

[Ralph Mason]

I finally gave up on this one.

I really would like build AVARICE on cygwin, so I could use the version that
is in cvs.  The released version with WinAVR is buggy.

Is there anyone out there with enough smarts to solve this.  I don't know
anything about configure, and I don't know what to tell it to solve this
one.

I have tried, and tried again.  The LIB is there, but I can not make it find
it.   Sometimes the simplest things just stump me.

I though perhaps I could remove the offending libs from configure.ac, (had
to also remove xmalloc) and modify the code not to support bfd lib, but then
configure craps out

checking for strtol... yes
configure: creating ./config.status
config.status: creating
.infig.status: error: cannot find input file:


Thanks for any help anyone can offer.

Ralph


My Problem again for all that missed it.

address@hidden /home/avarice
$ ./Bootstrap
+ aclocal
+ autoheader
+ autoconf
+ [ -d config-aux ]
+ automake -a -c
+ rm -f config.cache

address@hidden /home/avarice
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking for C++ compiler default output... a.exe
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... avr-gcc
checking whether we are using the GNU C compiler... yes
checking whether avr-gcc accepts -g... yes
checking for avr-gcc option to accept ANSI C... none needed
checking dependency style of avr-gcc... gcc3
checking for perl... /usr/bin/perl
checking for library containing gethostbyname... no
checking for socket... no
checking for socket in -lsocket... no
checking for socket in -lnsl... no
checking for library containing inet_aton... no
checking for library containing dcgettext... no
checking for xmalloc in -liberty... no
checking for bfd_init in -lbfd... no
configure: error: You need to install libbfd.a from binutils.

address@hidden /home/avarice
$ ls /lib/libbfd*
/lib/libbfd.a  /lib/libbfd.la

address@hidden /home/avarice
$

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of Joerg Wunsch
> Sent: Tuesday, 22 July 2003 5:45
> To: address@hidden
> Subject: Re: [avr-gcc-list] Building AVARICE on Cygwin
>
>
> As "Ralph Mason" <address@hidden> wrote:
>
> >I don't really understand why the complier generated an object
> file stops it
> >from linking (what else would the linker work with?) Does not the -l get
> >passed to the linker?
>
> Yes, the -l is a linker option.  The linker collects object modules.
> First, it collects all the .o modules explicitly named on the command
> line.  Then, it'll use the .a files to pick up further modules
> (precompiled .o files) from these libraries, but /only/ to satisfy
> symbols that are still undefined at this point in time.
>
> So in your example (let's assume the object file be named test.o for
> simplicity):
>
> ld [...] -lbfd test.o [...] -lc -lgcc -lc
>
> by the time test.o is seen, it generates an undefined reference to
> _bfd_init, but no library follows on the command line that could
> resolve this symbol.  The library that's supposed to resolve it came
> /before/ the symbol was even marked undefined.
>
> >How actually could I make this link?
>
> One way (the usual one):
>
> ld [...] test.o -lbfd [...] -lc -lgcc -lc
>
> or expressed in a call to cc
>
> cc test.c -lbfd
>
> Another way (the not so obvious one) is:
>
> ld [...] -u _bfd_init -lbfd test.o [...] -lc -lgcc -lc
>
> (or: cc -Wl,-u,_bfd_init -lbfd test.c)
>
> In the latter case, you explicitly mark _bfd_init as `undefined'
> before linking libbfd.a, that way the respective module will already
> be picked up from there even though your actual reference (in test.o)
> has not yet been seen.  That's not the usual way to arrange for it,
> but if you e. g. look into the documentation for avr-libc's printf()
> family, you can see that this trick is needed for example to get the
> floating point vfprintf() from another library.
> --
> J"org Wunsch                                         Unix support engineer
> address@hidden
> http://www.interface-systems.de/~j/
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003