[Bug-gnulib] Re: gnulib in libraries and applications

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> Currently, gnulib-tool doesn't support two gnulib directories in one
>> project without having two different configure.ac (which is what I use
>> in gsasl), so because I had gl_LGPL in configure.ac, importing the
>> exit module failed.
>
> Really, when a package installs a library and an application, I would
> recommend to have two configure.ac files.
>   - It avoids using GPLed code in the library inadvertently.
>   - It clarifies the package structure.
>   - It's just cleaner.

How do you handle conditional features?  For libidn, the library can
be compiled with and without TLD support (for discussion, it doesn't
matter what TLD is).  This is toggled by a config.h USE_TLD define.
The self tests and the command line tool use the same define.

For gsasl, the situation is worse, you can enable/disable client and
server code, you can enable/disable each of the 9 available
mechanisms, and a few other options.

Hm.  I guess one solution is to put the same AC_ARG_WITH(tld, ...)
code inside both the top-level configure.ac, and the library
configure.ac.  Hm.  Further, I guess it could even be argued that the
command line tool and self tests should be independent of the library,
so they shouldn't require the library's config.h.  I think I see your
point.

Still, I'm not sure this is a complete solution anyway.  In Shishi,
there is a similar situation, but all code is GPL.  Shishi have
several libraries, the core one in lib/, and an auxilliary library in
db/.  The db/ library is intended to be small and self contained.  But
it do use strdup, for instance, so it needs gnulib, but I don't want
the entire gnulib library inside the db/ library.  One reason for that
is the 'program_name' issue below, but I recall similar problems too..

> The only tricky thing is how to propagate the "configure --help" output
> from the sub-configures to the main configure file.

Yes.  I wish autoconf could recurse to generate a more helpful --help.
Really, why don't it?

>> Sigh, I liked this idea, but it wouldn't work.  The reason is that
>> many gnulib modules use AC_REPLACE_FUNCS, so you can't have more than
>> one directory that use @LTLIBOBJS@ without adding the same file to
>> every such directory.
>
> There is no problem with having the same .c and .o files being added to
> both the library's gnulib and the application's gnulib. They will be
> compiled twice, sure, but when linking the application, it doesn't matter:
>   - If in the application's link command line, the library comes before
>     the application's gnulib, the modules from the application's gnulib
>     will be ignored. Fine.
>   - Otherwise, if the library was built statically, the modules from the
>     library's gnulib will be ignored. Fine.
>   - Otherwise, if the library was built shared, the duplicated modules
>     will be both in the shared library and the application. That's wasted,
>     but still not a compilation error. (On MacOS X, you get a warning
>     for this. Oh well.)

This wasn't my experience.  I got a fatal linker error when linking
libidn.la that the symbol 'program_name' didn't resolve.  The library
only used strdup from gnulib, but it linked with the gnulib library.
The gnulib library included the progname module.  This was on many
platforms, I'm pretty sure HP-UX and Tru64 was among them.  (The
problem wouldn't occur on GNU platforms, since progname would use a
glibc internal symbol there...)

I think it would have been wrong for libidn to define 'program_name'.
Instead, I stopped using gnulib inside the library, and reverted my
only use of strdup for now...

> However, there is an optimization that "gnulib-tool --import" could do:
> If you could specify a set of modules which can be assumed to be
> implicitly present (say, an option --omit), then gnulib-tool could omit
> from the application's gnulib those modules which are already contained
> in the library's gnulib:
>
>   gnulib-tool --import --dir=lgl ...
>   gnulib-tool --import --dir=gl --omit="`list-modules gl`" ...

This seems nice, but I don't want to worry about optimization until
things work.

Thanks.