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

[Ralph Mason]

This is all making no sense to me at all now.

$ nm libbfd.a | grep bfd_init
00000000 T _bfd_init

So it seems it's there.  But ...

$ cat test.c
#include <bfd.h>

int
main ()
{
bfd_init ();
  ;
  return 0;
}


$ gcc -lbfd test.c
/cygdrive/p/TEMP/ccmHuQtQ.o(.text+0x1f):test.c: undefined reference to
`_bfd_init'
collect2: ld returned 1 exit status

I must be missing something simple.

Ralph


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of Joerg Wunsch
> Sent: Monday, 21 July 2003 2:23
> To: address@hidden
> Subject: Re: [avr-gcc-list] Building AVARICE on Cygwin
>
>
> As "Ralph Mason" <address@hidden> wrote:
>
> >Is there any way to dump a library and see the entry points (dumpbin
> >with msvc)? (my lib is just in /lib btw and I did set LD_FLAGS to
> >-L/lib)
>
> Yes, the »nm« tool does this.  It displays you the name list of an
> object file (or an object file library).  What you're looking for is
> symbols marked with a `T' in the second column, that's globally
> defined symbols within the text segment.  The first column is the
> defined value (resp. address), the third column is the actual name
> defined by this entry.  Upper-case letters mark global symbols,
> lower-case means a (module-)local symbol.  `D' is for data segment
> symbols (initalized variables), `T' for the text segment (usually
> function entry points), `W' is for `weak' global symbols which can be
> overridden by the application without causing a complaint by the
> linker (so a library can define an overridable default symbol).  `C'
> is a ``common'' symbol, basically an uninitialized variable.  The term
> `COMMON' can probably only be understood if you ever happened to
> program in FORTRAN.  It's merely a historical remnant that Unix C
> compilers usually declare .bss variables that way instead of actually
> reserving space in .bss (which would be a `B' in the nm listing).
> Common-style uninitialized variables allow for sloppy extern
> declarations in header files like:
>
> int foobar;
>
> where the header file may be included by one or more C files.  Due to
> the common-block notation, all symbols `foobar' will then be overlaid
> by the linker.  This style seems to have been predominant in old Unix
> source files.  The politically correct style would be to have
>
> extern int foobar;
>
> in the header file, and exactly one C source file with
>
> int foobar;
>
> (If you run gcc with -fno-common, it'll actually allocate the .bss
> variables in that way so you get linker errors for the sloppy style.)
>
> Finally, there's `U', standing for an undefined symbols,
> i. e. something that needs to be resolved by the linker.
> --
> 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