bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: circular link dependency: libmailutils.a and libmailbox.a


From: Alain Magloire
Subject: Re: circular link dependency: libmailutils.a and libmailbox.a
Date: Mon, 13 May 2002 00:13:19 -0400 (EDT)

> 
> Bonsoir!
> 
> Quoteing address@hidden, on Sun, May 12, 2002 at 12:56:42PM -0400:
> > > 
> > > mu_argp.c, in particular, makes calls into libmailbox.a. This has
> > > tended to work because those functions are in mutil.c, and mutil.c
> > > tends to have been needed by something in mailbox/ before the
> > > linker got to the libmailutils.a. But, its just lucky, and now
> > > I'm unlucky.
> > 
> > - mailutils/lib/* are just replacement functions for things
> >   like strcasecmp () etc .. or functions shared by the
> >   utilities.
> 
> Those shared functions need to link against libmailbox.a.
> 
> > - mailutils/mailbox/* should not need anything explicitely from
> >   mailutils/lib/*.  mailbox/* is under LGPL.
> >   In theory, if you have a POSIX compliant system mailutils/mailbox
> >   will build standalone.
> > 
> > > 
> > > Can we move mu_argp.c/h into mailbox/?
> > 
> > This seems like code only use by the utilities(frm, mail, ... etc)
> > not mailbox.  I do not see any reference to mu_argp in mutil.c
> 
> Correct, it's the other way around.
> 
> libmailutils.a has references to libmailbox.a, but libmailbox.a
> doesn't appear in the linker command line after libmailutils.a.

Do you know what libmailutils.a needs from libmailbox.a ?
libmailutils.a is suppose to be a support lib or compatibility
libs of missing functions only.

I see that we have also use it as a place holder for common
functionnalities that could not go in libmailbox.a because of
License issues

> frm -> mailbox
>     -> lib -> mailbox
> 
> So far this has worked, because what happens is:
> 
> frm -> mailbox/...,mutil.c
>     -> mu_argp.c -> mailbox/mutil.c
> 
>     So mutil.c was already linked in by the time mu_argp.c needed it.
> 
> But I now have:
> 
> frm -> mailbox/...,mutil.c
>     -> mu_argp.c -> mailbox/(mutil.c,mailer.c)
> 
> 
> frm doesn't need mailer.c, so it isn't linked in, then whe mu_argp.c
> needs it, its too late.
> 
> My hack-around is this:
> 
> mutil.c:  void* mu_forced_mailer_o_reference = mailer_get_url_default;
> 
> 
> You can reproduce the problem by compiling this:
> 
> ----------
> #include "mu_argp.h"
> 
> int main()
> {
>     return (int) mu_argp_parse;
> }
> ----------
> 
> cc -g -I../include -Wall -I../lib  -g -static  muargp.c ../mailbox/.libs/libma
> ilbox.a ../lib/.libs/libmailutils.a  -lsocket -o muargp
> ./lib/.libs/libmailutils.a(mu_argp.o): In function `mu_common_argp_parser':
> mu_argp.o(.text+0x160): undefined reference to `mu_path_maildir'
> mu_argp.o(.text+0x1e8): undefined reference to `locker_set_default_flags'
> ... tons of other stuff.
> 
> Lots of ways around this, makeing mu_argp it's own library, libmailbox.a
> show up twice in the link line, my ugly hack, moving mu_argp into
> mailbox, etc.
> 

It used to be a library of its own.
The problem, as you pointing out, is that it needs reference from libmailbox.a

We could move the entire thing in mailutils/mailbox/*  but we need to make it
LGPL.  The bits that are not LGPL is the one written by Sergey, I vaguely 
remember
that he did not have any objections to this(make it LGPL).

Later, working late ... again 8-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]