Mailing List Archive

libtool support about to be added
I'd about to add libtool support so that libzebra and the ospf libs
can be shared. My experiences with libtool lead me to believe this
won't cause trouble, but we can certainly back this out if it does.

--
Greg Troxel <gdt@ir.bbn.com>
Re: libtool support about to be added [ In reply to ]
While trying this out, I found something curious: All/most of daemons
(besides zebra) build most of their .os into a library, and all but
ospfd do not install this library.

Can anyone explain why these libraries exist? Does anyone use them?
It seems that the ospf one should not be installed, and probably the
library should not even be built, since the link line for ospfd
doesn't use it, instead putting

ospfd_SOURCES = \
ospf_main.c $(libospf_a_SOURCES)

I'm hesitant to change this without understanding why it's there, but
I'd like to make libospf "noinst_" (to avoid installing it).

--
Greg Troxel <gdt@ir.bbn.com>
Re: libtool support about to be added [ In reply to ]
On Wed, 30 Jun 2004, Greg Troxel wrote:

> While trying this out, I found something curious: All/most of
> daemons (besides zebra) build most of their .os into a library, and
> all but ospfd do not install this library.
>
> Can anyone explain why these libraries exist?

No idea really. Maybe Kunihiro reckoned some of the functions would
be more generally useful, no idea really.

> Does anyone use them?

OSPF-API uses libospf.

> It seems that the ospf one should not be installed, and probably
> the library should not even be built, since the link line for ospfd
> doesn't use it, instead putting
>
> ospfd_SOURCES = \
> ospf_main.c $(libospf_a_SOURCES)
>
> I'm hesitant to change this without understanding why it's there, but
> I'd like to make libospf "noinst_" (to avoid installing it).

OSPF-API needs it. So it needs to be installed if one wishes to link
OSPF-API using applications. For the RPMs, it's only installed with
the quagga-devel package.

Feel free to suggest better ways. Eg, ospf_api.o could be made into a
shared library as well as libospf. (?)

> --
> Greg Troxel <gdt@ir.bbn.com>

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Tact is the art of making a point without making an enemy.
Re: libtool support about to be added [ In reply to ]
Paul Jakma <paul@clubi.ie> writes:

> On Wed, 30 Jun 2004, Greg Troxel wrote:

> > It seems that the ospf one should not be installed, and probably the
> > library should not even be built, since the link line for ospfd
> > doesn't use it, instead putting
> >
> > ospfd_SOURCES = \
> > ospf_main.c $(libospf_a_SOURCES)
> >
> > I'm hesitant to change this without understanding why it's there, but
> > I'd like to make libospf "noinst_" (to avoid installing it).
>
> OSPF-API needs it. So it needs to be installed if one wishes to link
> OSPF-API using applications. For the RPMs, it's only installed with
> the quagga-devel package.

Ah, so libospf should be installed, and thus might as well be shared.

> Feel free to suggest better ways. Eg, ospf_api.o could be made into a
> shared library as well as libospf. (?)

seems suboptimal for the bulk of ospfd to get linked into a program
that wants to get at the LSA db. Perhaps eventually we can split out
only the files that are needed. A quick attempt to link with only a
few didn't lead to success. My guess is that a strategy of
identifying the functions that are needed and putting them in their
own files is sensible, but only after clearly documenting the intended
dependencies.

For now I'll just make the ospf library shared.

--
Greg Troxel <gdt@ir.bbn.com>
Re: libtool support about to be added [ In reply to ]
[re libospf]

OSPF-API needs it. So it needs to be installed if one wishes to link
OSPF-API using applications. For the RPMs, it's only installed with
the quagga-devel package.

I'm not an RPM expert, but:

It would seem that the .so versions of the libraries belong in the
base package (since a program linked with them will need it). The .a
versions and the include files belong in the -devel package.

One could also split the apiclient stuff into
quagga-ospfclient{,-devel}, but that would only save about 250k, and
it doesn't seem worth it.

--
Greg Troxel <gdt@ir.bbn.com>
Re: libtool support about to be added [ In reply to ]
On Thu, 1 Jul 2004, Greg Troxel wrote:

> It would seem that the .so versions of the libraries belong in the
> base package (since a program linked with them will need it). The
> .a versions and the include files belong in the -devel package.

right. currently there's only static libs, so they're only in -devel.

> One could also split the apiclient stuff into
> quagga-ospfclient{,-devel}, but that would only save about 250k, and
> it doesn't seem worth it.

probably not, no.

> Greg Troxel <gdt@ir.bbn.com>

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
I'm not tense, just terribly, terribly alert!