Mail Archives: djgpp/2001/06/08/07:04:29
Tim Van Holder wrote:
> >
> > A block data is never called, and if the object is in a
> > library, it is never linked.
> >
>
> It may not be 'called', but since you use it, the linker
> would pull it in. One possibility is that the name of the
> exported symbol is the same as a symbol in some other
> library that is checked first. What do 'nm object.o' and
> 'nm lib-with-object.a' print?
>
The name is unique, over51.o
The output of nm as you suggest follows
ar -rv tpbig.a over51.o
ranlib tpbig
nm tpbig.a
over51.o:
000957b0 b .bss
00000010 d .data
00000000 t .text
00000000 t ___gnu_compiled_c
00000010 D _killcode_mup__
00000000 T _over51_
00000000 t gcc2_compiled.
nm over51.o
000957b0 b .bss
00000010 d .data
00000000 t .text
00000000 t ___gnu_compiled_c
00000010 D _killcode_mup__
00000000 T _over51_
00000000 t gcc2_compiled.
With the block data converted to subroutine:
OVER51.O:
000957b0 b .bss
00000010 d .data
00000000 t .text
00000000 t ___gnu_compiled_c
00000010 D _killcode_mup__
00000000 T _over51_
00000000 t gcc2_compiled.
As you can see, the output is the same in all cases.
I converted the block data to a subroutine with only the
data lines in it. I call this subroutine early in the main,
and all works OK. The object was included in library and in
is pulled in without problem.
No extra time at run time, the assignment of 640kB of text
data is done in a very short time.
If there is another procedure to force pull in a block data
from a library, it will be welcome.
Thanks you.
OPH. 2001-6-8 8:02
Ing. Orlando P. Hevia
heviaop AT ssdfe DOT com DOT ar
Santa Fe-Argentina
- Raw text -