RE: How handle static libraries?

RE: How handle static libraries?

[lrtaylor]

Bo,

Basically, the common way to do it is the way you're doing it.  If C
uses A and you use C, you link to both C and A (in that order).
Something you might look at, however, is .la files (usually created by
libtool, I believe).  These are information files that the
compiler/linker can use to know how to use a given library.  It may also
be able to tell the compiler what libraries your library depends on so
that it can link them in automatically.  Now, I'm not very familiar with
these files and how they work, but it might be something you would want
to look into.  You may find your answer there.

Good luck,
Lyle

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Bo Do


My question in this post is actually: What is the common way to
handle/create
static libraries which uses other libraries?

Thanks for reading this post. Don't know if it makes sense! =)
/Bo
 

Re: How handle static libraries?

[Bo Do]

Thank you Lyle for clearing things up. =)
I'll take a look at .la stuff.

Thanks everyone for pointing me in the right direction.
/Bo

----- Original Message ----- 
From: <lrtaylor@micron.com>
To: <bodo@flygp.se>; <gcc-help@gcc.gnu.org>
Sent: Tuesday, November 18, 2003 7:20 PM
Subject: RE: How handle static libraries?


Bo,

Basically, the common way to do it is the way you're doing it.  If C
uses A and you use C, you link to both C and A (in that order).
Something you might look at, however, is .la files (usually created by
libtool, I believe).  These are information files that the
compiler/linker can use to know how to use a given library.  It may also
be able to tell the compiler what libraries your library depends on so
that it can link them in automatically.  Now, I'm not very familiar with
these files and how they work, but it might be something you would want
to look into.  You may find your answer there.

Good luck,
Lyle

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Bo Do


My question in this post is actually: What is the common way to
handle/create
static libraries which uses other libraries?

Thanks for reading this post. Don't know if it makes sense! =)
/Bo
 

How handle static libraries?

[Bo Do]

Hey all,

I've written some (static) libraries I use pretty often. Lets call them A, B, C.....
When I want to use one, lets say B, I simply include B.h and link in B in my program.

My question is, I have a library C which needs/uses library A. Can I compile/archive
C in some way so that when I want to use C in a program, I just include C.h and link in C?
What I have to do now is to also link A to my program. But this look wierd (to me!)
because my program doesn't use A.

Thanks for any tip,
/Bo

Re: How handle static libraries?

[Erik Christiansen]

On Mon, Nov 17, 2003 at 10:17:41AM +0100, Bo Do wrote:
> My question is, I have a library C which needs/uses library A. Can I
> compile/archive C in some way so that when I want to use C in a
> program, I just include C.h and link in C?

From: man ar;

       The GNU ar program creates, modifies,  and  extracts  from
       archives.   An  archive is a single file holding a collec­
       tion of other files in a structure that makes it  possible
       to  retrieve the original individual files (called members
       of the archive).

      ...

       ar is considered a binary utility because archives of this
       sort  are  most  often  used as libraries holding commonly
       needed subroutines.

      ...

Haven't used it myself, but there should be examples of its use in the
makefiles for gcc, etc. (I've seen "ar" commands whiz by, and they
seemed to be doing roughly what you intend, as far as a fleeting glimpse
can tell.)

At least, it's worth a look.

Erik

Re: How handle static libraries?

[Bo Do]

Thanks for the tip and trying Erik. =)

I'm already using ar to create my static libraries.
My problem is that I'm currently writing/creating a library, call it C.
In this library, C, I use functions provided by library A.

This means that if I want to use C in a program, I'll have to link
both C and A to it! This is not very logical for the user who just want C!

Alternativly, when I create the C library, I could archive A toghether
with it. I.e. creating a library containing both A+C and just call it C.
This way the user/program doesn't have to know about A.
But, the question here is:
What if the user/program itself uses both A and C? Library A will be 
"linked twice", once in A and once in C.
I don't think this is a problem (with double defined symbols), but won't the
executable code be quite large? Especially if A is big?
Or will the linker just link a minimal set of object files needed?

My question in this post is actually: What is the common way to handle/create
static libraries which uses other libraries?

Thanks for reading this post. Don't know if it makes sense! =)
/Bo

----- Original Message ----- 
From: "Erik Christiansen" <erik@dd.nec.com.au>
To: "Bo Do" <bodo@flygp.se>
Cc: <gcc-help@gcc.gnu.org>
Sent: Tuesday, November 18, 2003 12:14 AM
Subject: Re: How handle static libraries?


> On Mon, Nov 17, 2003 at 10:17:41AM +0100, Bo Do wrote:
> > My question is, I have a library C which needs/uses library A. Can I
> > compile/archive C in some way so that when I want to use C in a
> > program, I just include C.h and link in C?
> 
> From: man ar;
> 
>        The GNU ar program creates, modifies,  and  extracts  from
>        archives.   An  archive is a single file holding a collec­
>        tion of other files in a structure that makes it  possible
>        to  retrieve the original individual files (called members
>        of the archive).
> 
>       ...
> 
>        ar is considered a binary utility because archives of this
>        sort  are  most  often  used as libraries holding commonly
>        needed subroutines.
> 
>       ...
> 
> Haven't used it myself, but there should be examples of its use in the
> makefiles for gcc, etc. (I've seen "ar" commands whiz by, and they
> seemed to be doing roughly what you intend, as far as a fleeting glimpse
> can tell.)
> 
> At least, it's worth a look.
> 
> Erik
>