libtool-patches
[Top][All Lists]
Advanced

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

the ltdl issue(s)


From: Ralf Wildenhues
Subject: the ltdl issue(s)
Date: Thu, 18 Aug 2005 19:31:31 +0200
User-agent: Mutt/1.4.1i

A little rant:  There are just too many combinations.
(There is also useful information at the end, after the ######).

Suppose you would like to use libltdl.  You could:

a) Use only an installed libltdl, do not ship your own at all
b) Ship your own, but do not install that
c) Ship your own, also install in (some) appropriate directories.

Some of these are changeable by both the package author and the user.

Mix that with

1) Use neither Automake nor Libtool
2) Use Libtool but not Automake
3) Use both

A) static libs,
B) shared libs
C) both specifyable by both the user and the author, subject to system
   side conditions,

i ) Use branch-1-5 Libtool (maybe and libltdl)
ii) Use newer Libtool (maybe and libltdl)
    (ideally without source-code changes)

and mix that with data points important to us:

- Use of AC_CONFIG_AUX_DIR or not
- Use of AC_CONFIG_MACRO_DIR or not
- Use of AC_CONFIG_HEADERS or not
- libltdl.la might be called ltdl.la
- the libltdl/ subdir might be called differently.

Wait!  There's more:
- build libltdl as subpackage (two configure's) or not
  (request: don't install libltdl/configure in the latter case)
- try to build a non-recursive Makefile or not
- build with subdir-objects or not
- Optionally: do not ship (have `libtoolize --ltdl..' install)
    libltdl/m4/*
    libltdl/config/*
    libltdl/{config-h.in,configure.ac,configure}
  (this is a feature request for a new `libtoolize' option!
  I realize that, without changes to libltdl/Makefile.am, this will only
  work in the non-subpackage case).

Some of these thousands of possibilities don't actually make sense.
However, we advertise most of them for upcoming 2.0, and some just don't
work, because we do not test them.

This sucks.  Some have been reported umpteen times, too.

##############

Progress:

[ the following holds for CVS HEAD, assuming my outstanding patch from
the thread "Fix ltdl files installation" is applied. ]


- At least one issue we have cared for (and seems to actually work when
my proposed Autoconf/Libtool patching is in): Use of autoheader is forced,
and CONFIG_H set appropriately for a package with non-subpackage libltdl


- Another issue reported by Bob in
http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00271.html
(gosh, that's a long time!  It's the oldest bug I'm tracking ATM) is
fixed as follows, I believe:

If libltdl is not to be a subpackage (i.e.: no subconfigure), the user
also needs to add  LTDL_INIT to his configure.ac (and also
libltdl/Makefile to AC_CONFIG_FILES).  Like this:

AC_INIT(foo, 0.1, address@hidden)
AC_CONFIG_SRCDIR(foo.c)
AM_INIT_AUTOMAKE(foreign)
LTDL_INSTALLABLE(ltdl)
LT_INIT(dlopen)
LT_WITH_LTDL(ltdl)
LTDL_INIT
AC_CONFIG_FILES(Makefile ltdl/Makefile)
AC_OUTPUT

(Don't forget to add `ltdl' to SUBDIRS in Makefile.am.)
We need to document that, if we can agree this is the correct thing
to do.


Then there is only one minor buglet left in CVS HEAD to make this work:
we need to actually omit the AC_CONFIG_SUBDIRS call, like in this
workaround:
 
| --- use-ltdl1/m4/ltdl.m4        2005-08-18 11:55:23.000000000 +0200
| +++ use-ltdl1-nosubpkg/m4/ltdl.m4       2005-08-18 18:00:37.000000000 +0200
| @@ -48,7 +48,7 @@
|  AC_MSG_CHECKING([whether to use included libltdl])
|  AC_MSG_RESULT([$with_included_ltdl])
| 
| -AC_CONFIG_SUBDIRS(m4_if($#, 1, [$1], [libltdl]))
| +dnl AC_CONFIG_SUBDIRS(m4_if($#, 1, [$1], [libltdl]))
|  ])# LT_WITH_LTDL
| 
|  # Old name:
| 

Gary, do you easily see how we can achieve this?  Maybe an LT_INIT
option `ltdl-subpkg' or something simple?

Cheers,
Ralf (now off to looking at other cases)




reply via email to

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