linking application with a library

Kai Ruottu
Thu Nov 15 06:15:00 GMT 2001

Mohammad Saleem wrote:
> Hi all,
> I am using h8300-hitachi-hms-gcc cross-complier for building my application.
> I have a lib mylib.a (20 kb) which I want to link with my application.
> My application gets 20 kb bigger as soon as I link it with mylib.a
> without any function being called from mylib.a.

 The linker shouldn't take anything from the lib if it doesn't need anything
from it.

> It seems to me that I have built mylib.a so that the whole lib is linked
> during linking process even if no one method is being called.

 Is the library produced using C++ or ObjC or from where the name 'method'

> Now my question is which flag should I use to build mylib.a so that only
> those functions are linked which are being called.

 Compiling each function into its own '.o' module is the normal practice,
the linker takes only the needed '.o' files from the archive.
> If no function is called then linking mylib.a shouldn't affect the size
> of my application.

 Yes, this should be the case...

 BTW, the H8/300 is a architecture which requires tricks like using
the '__attribute__((eightbit_data))' for the SFRs (I/O-registers) in
order to produce any effective code...  For instance:

-------------------- clip --------------------------------
#define SFR       __attribute__((eightbit_data))

extern volatile unsigned char SFR SCI_SSR0;
extern volatile unsigned char SFR SCI_TDR0;

#define SCI_TDR0 (*(volatile unsigned char *) (0xffffdb))
#define SCI_SSR0 (*(volatile unsigned char *) (0xffffdc))

/* Single char out to the serial port */

void put_ser(unsigned char c)
        while ((SCI_SSR0 & 0x80) != 0x80)
        SCI_TDR0 = c;
        SCI_SSR0 &= 0x7F;
-------------------- clip --------------------------------
;       GCC For the Hitachi H8/300
;       By Hitachi America Ltd and Cygnus Support
;       release F-1
; -O2

        .file   "put_ser.c"
        .section .text
        .align 1
        .global _put_ser
        mov.b   @_SCI_SSR0:8,r2l
        and     #128,r2l
        beq     .L5
        mov.b   r0l,@_SCI_TDR0:8
        bclr    #7,@_SCI_SSR0:8
-------------------- clip --------------------------------

 Getting a RISC-like 'load/and/store' operation instead of the
'bclr #7,@_SCI_SSR0:8' is not rare if not using any of these
'tricks'... And if the I/O-ports are used much, much 'code
bloat' will be the result...

Cheers, Kai

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list