Stephen.
A. Why not to link in the whole library
I almost always link the whole library as a Q&D method to get past
"unsatisfied references" initially, but there are two reasons why I don't
recommend linking the whole library; No, let me make a stronger statement:
There are two reasons why I recommend not linking the whole library.
1. As you noted, this adds nearly a megabyte per module. While
this isn't much with today's systems when you're adding just one module, we
have systems that have our drivers modularized into as many as 8-10
different modules. If I included the whole library with each one that
needed it (about half), then we'd have 4-5 MB of library choking a 64 MB
system when we only need, maybe, 25 KB total. I would not deprecate loading
the whole library (but see #2 below) if there was an easy way to make the
functions (or at least some of them) in the library "external" in the kernel
once the library was loaded so I didn't have to include multiple copies of
it. (There is a way using a script for the loader, but it's quite esoteric
and can't be maintained by lower level personnel after I move on to the next
project [or retire].)
2. In the Intel implementation (the one I'm familiar with) the
entire gcc-library is "self-contained" but there are other architectures
(Alpha has come to light recently) in which various functions in the library
have links to I/O functions (sprintf and fputs come to mind) for writing
diagnostics. Even if the specific modules needed by your driver don't
reference them directly or indirectly, loading that library linked with the
driver would then require either a module of stubs to satisfy these
extraneous external references or linking in another (dangerous) library.
There's one more reason that I don't mention very often:
3. It has happened (to me when I was including the whole library)
that I referenced the name of a function which happened to be in the library
and which duplicated a name I was going to use (for good reason) and which
then forced me to either change the name in several files or to link in just
the stuff from the library I needed.
B. Finding the gcc library
There are a couple of more ways too. I didn't think that mine was
that convoluted and that it was likely to change, although yours is slightly
more portable between architectures if that's a consideration, though I
could probably make the output of find do what gcc does in your method.
(Portability of drivers to different architectures usually isn't a concern
for most of us using rtlinux.)
C. I can't (at least not off the top of my head) think of a way to have the
Makefile perform a recursive extraction of modules from the library in the
case that one needed module then required another module from the library.
Also, while I haven't run into the situation yet, there is (always) the
possibility that an external reference is not in a module of the same name;
while there might be an automatable way to handle this, it could get really
ugly really quickly.
Norm
-----Original Message-----
From: Stephen D. Cohen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 13, 2001 9:02 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [rtl] unresolved symbols when using uint64_t
Recently, Norm Dresner wrote:
> I don't know which operations resulted in the function calls you have,
> but there are three possible (generic) solutions to the problem:
> 1. Remove the offending operations from the source (not your
> first choice, I'm sure)
> 2. Include in the link the entire gcc library; it can be done,
> but it's not wise
I would like to read a discourse on why this is not wise. It is the
method we have been using for the past two years with no trouble. This
approach also moves the burden for figuring out which modules need to be
linked to the linker.
> 3. (Most recommended, at least by me) Extract from the gcc
> library the routines you need to satisfy the unresolved symbols you
> have (and, recursively, any that they require as well) and link these
> few modules into your device driver/module.
>
> On my (RedHat 6.2-derived) system, the library is located at
>
> /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/libgcc.a
> The simple way to locate it is to do a search with find for the
> file libgcc.a
> find /usr/lib -name libgcc.a -print
Actually, the simplest way to find it is to let gcc tell you where
it is:
gcc -print-libgcc-file-name
I use this in a Makefile with:
LIBGCC := $(shell $(CC) -print-libgcc-file-name)
And on the LD line:
$(LD) -r -o my_module.o $(OBJS) $(LIBPATHS) -static $(LIBS) ${LIBGCC}
> Once you locate it, you can use ar to list the contents of the
> library and to "extract" (really a copy-out, not a removal) single
> modules from it. Then put these into your link
Yep, that will work. You can also just link to the whole library if
you do not have strict memory constraints. On my system the libgcc.a
library adds about 800KB to the size of the module.
Alternatively, you could set your Makefile up to extract the correct
modules from the library and add them to your linkage line. That would save
you having the various library .o cruft laying around. Another option would
be to build your own library using the appropriate tools (ar, mostly) of
just the modules you need and put it somewhere special.
Regards,
Steve
--------------------------
Stephen D. Cohen
Engineering Manager
Xybion Sensor Positioning Systems
11528 53rd Street North
Clearwater, FL 33760
Voice: (727) 299-0150
Fax: (727) 299-0804
[EMAIL PROTECTED]
www.xybion.com
************************************************************************
THIS EMAIL, AND ANY ATTACHMENTS, CONTAINS CONFIDENTIAL AND PRIVILEGED
INFORMATION INTENDED FOR THE USE OF THE ADDRESSEE. IF YOU ARE NOT THE
INTENDED RECIPIENT OR AN AUTHORIZED REPRESENTATIVE OF THE RECIPIENT, DO NOT
READ OR DISTRIBUTE THE CONTENTS OF THIS EMAIL AND DELETE IT FROM YOUR
SYSTEM. THIS EMAIL AND ALL ATTACHMENTS HAVE BEEN SCANNED FOR VIRUSES AND ARE
BELIEVED TO BE VIRUS FREE. HOWEVER, IT IS THE RECIPIENT'S RESPONSIBILITY TO
ENSURE THAT THEY ARE VIRUS FREE. XYBION DOES NOT ACCEPT ANY RESPONSIBILITY
FOR ANY LOSS OR DAMAGE ARISING IN ANY WAY FROM USE OF THIS EMAIL AND
ATTACHMENTS. XYBION ALSO DOES NOT ACCEPT RESPONSIBILITY FOR PERSONAL EMAIL
OR EMAIL NOT ASSOCIATED WITH ITS BUSINESS PURPOSES.
************************************************************************
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
