Mail Archives: djgpp/1998/11/05/12:30:22
On 5 Nov 1998 08:02:30 GMT, "Alberto Chessa"
<achessa AT fiar DOT finmeccanica DOT it> wrote:
>Mapson <mapson AT mapson DOT com> wrote in article
> Remember that You have to use one .c files for each function
>if you want to be able to retrive the single function out of a lib. If all
>the function are on the same file, you compile on a single .o the will be
>included in the lib as a single entity: whenever you reference a symbol
>defined in this .o, the linker extract and link the whole .o
This was something I've considered. However, I am getting conflicting
information on this issue. Could it be that different compilers are
different on this issue?
<...>
>Do You declare global variables as 'extern' ?
I hadn't here; I should have, I now see.
I didn't need to before- because before these libs, my little
flex/bison-assited "compiler" merely constructed a single giant C++
file out of lots of small parts put in the right order to have
includes, globals and definitions at the top, code below. Worked
wonderfully- but I figured it was oversized, since at any given time
the User (any one of the people in my lab) may only need one or even
none of the potentially hundreds of lab hardware-specific functions I
created from his personal setup file. Now I take those tailored
functions (which tend to stay the same way permanently with a given
user on a given configuration) and automatically create a lib with
them. To my surprise, just by linking to the lib, my executables are
larger than they were in my original method.
To some extent, I still like the lib method, because even without the
"weight-loss", linking lots of little snippets together to make a big
file is... prone to mis-ordering, makes debugging the file more of a
pain, and means I have to designate certain special places on drives
to keep these temporary files where they won't get corrupted, etc.
But I am beginning to wonder if my original method wasn't simply more
reliable, because the libs have their own strange occasional wierd
warnings that I hadn't seen before. Like, warnings about my serial
port stuff when a particular program had absolutely no serial port
calls- whereas other programs with and without serial port calls give
no errors. (possibly order of linking problems???). It wasn't quite as
transparent as I'd expected, and gets me a bit more paranoid about
reliability.
As it stands, I am going to think about this for a couple days... then
probably go ahead and go for the original method. The size of these
executables is not outrageous even with 50 or so hardware-specific
functions included- a shade under 200K.
>Your include file should declare variables as 'extern': this do not reserve
>space for the symbols but say to the compiler that somewhere exist an
>istance of these variables. The variables will be allocated in the
>implementation file only (same declaration, without 'extern').
<...>
Thanks for taking the time, esp. for the examples- between you and
Eli, I think I should soon get this pretty firmly nailed in my head.
- Raw text -