This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: [ECOS] Library Circularity Question
- To: "'eCos Discussion'" <ecos-discuss@sourceware.cygnus.com>
- Subject: Re: [ECOS] Library Circularity Question
- From: erikh@msoft.com (Erik Horstkotte)
- Date: Wed, 7 Jul 1999 15:47:17 -0700
- Cc: "John Mills" <Jmills@TGA.com>
- References: <FD7521AABD30D2118284006008AE0B6E03BFC0@ns1.tga.com>
> Originally I provided a dummy 'delete' operator to satisfy linkage of a
> pro-forma C++ destructor. The problem came up when I tried to find a linkage
> sequence which would actually implement some dynamic storage allocation and
> deallocation. Linking with "-lgcc"
> [from "<tooldir>/lib/gcc-lib/sh-hms/2.9-ecosSWtools-990310/libgcc.a"] left
> unresolved symbols; adding a trailing link command "-lc" didn't resolve all;
> but adding a _second_ "-lgcc" after "-lc" resolved all symbols:
> $(XLD) $(LDFLAGS) -o $@ ${OBJS} -lgcc -lc -lgcc
It's a characteristic of the GNU linker, and the older Unix "ld" linkers. By default,
they only look externals up in each library once, from left to right. If a library on the
right externs something that's public in a library to its left, it won't find it.
Either specify the libraries more than once, as you did, or use the -( and -)
linker options to force the linker to check the libraries repeatedly, like the linkers
you're probably familiar with.
-- Erik