libtool-patches
[Top][All Lists]
Advanced

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

Re: support standalone libltdl [libtool--gary--1.0--patch-23]


From: Ralf Wildenhues
Subject: Re: support standalone libltdl [libtool--gary--1.0--patch-23]
Date: Fri, 13 May 2005 14:13:26 +0200
User-agent: Mutt/1.4.1i

Hi Gary,

* Gary V. Vaughan wrote on Tue, Apr 26, 2005 at 03:13:17PM CEST:
> 
> This changeset requires autoconf and automake patched according to:
> 
>   http://lists.gnu.org/archive/html/autoconf-patches/2005-04/msg00028.html
> 
> But I think it is fine for HEAD to rely on CVS autoconf/automake, although
> I don't want to commit until the above patches are in too.

I've tried it now, with patched automake as per outstanding patch.
See report below.

> That done, a backport to branch-2-0 will require reverting to running
> libltdl/configure as a subconfigure, otherwise we can't release it
> bootstrapped with autoconf-2.59 and automake-1.9.5.

ACK.

> HOWEVER: autoconf-2.59 still doesn't recognise Darwin's use of -lcrt2.o
> in g77, so the fortran tests will always fail on Darwin.  Maybe we should
> bootstrap even branch-2-0 with CVS autoconf to avoid that problem?  If
> we decide to do that, then it might ease our maintenance burden to backport
> this patch more or less as is (without a subconfigure hack)... the whole
> changeset is, after all, inspired by a bug in branch-2-0.  Thoughts?

To reiterate:
I'm quite uneasy with releasing something the users can't re-bootstrap.
Distributions hate this.  I'd probably favor a release bootstrapped with
2.59 with the two patches we care about added.  But that may just be me.

> After the backport (in whatever form it eventually takes), is there
> anything else holding back a 2.0 release that I've forgotten?  If not,
> I propose an alpha release, and a round of testing, with 2.0 a few weeks
> later! :-D

My outstanding forward posts.  If you'd like to help, you could try to
answer my question about how to solve the _LT_COMPILER_OPTION problem in
http://lists.gnu.org/archive/html/libtool-patches/2005-04/msg00143.html
for a start, given your side condition that I should not proliferate use
of per-tag variables without tag.  (The question was, whether the former
names of _LT_COMPILER_OPTION/_LT_LINKER_OPTION are published interfaces
and may thus not change interface).

> Okay to commit (after autoconf & automake changes are in CVS)?

No, because of several issues:

arch2cvs (or whatever its name) bugs:
- Your standalone.at shows up in Users/gary/..., not where it should.
- Renames are not translated.
Both of these are mere inconvenieces, however.

Other bugs:

You have some other patches in your tree which makes this throw
rejects in libtoolize.m4sh.  (Only inconvenient, not a bug.)

tests/*/Makefile.am need ACLOCAL_AMFLAGS adjusted to -I ../../libltdl/m4.

tests/*/configure.ac need AC_CONFIG_AUX_DIR adjusted similarly.

`make clean; make' fails because no rule creates `libtool':
| make[2]: Entering directory `/tmp/libtool/build-x86_64'
| if /bin/sh ./libtool --tag=CC   --mode=compile gcc 
-DHAVE_CONFIG_H="<config.h>" -DLTDL -I. -I.. -I.  -DLTDLOPEN=libltdl -I. 
-Ilibltdl -I../libltdl -I../libltdl/libltdl   -g -O2 -MT 
libltdl/loaders/libltdl_libltdl_la-preopen.lo -MD -MP -MF 
"libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Tpo" -c -o 
libltdl/loaders/libltdl_libltdl_la-preopen.lo `test -f 
'libltdl/loaders/preopen.c' || echo '../'`libltdl/loaders/preopen.c; \
| then mv -f "libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Tpo" 
"libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Plo"; else rm -f 
"libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Tpo"; exit 1; fi
| /bin/sh: ./libtool: No such file or directory

`make clean' fails to remove libltdl/lt__strl.lo, but it removes
libltdl/.libs/lt__strl.o, causing build failure.

`make uninstall' fails to remove anything below $prefix/share/libtool
and below include/libltdl.

mdemo-make, mdemo-dryrun fail (remember you need to delete
$top_builddir/libltdl/Makefile before testing!):
| (cd ../../libltdl; make `echo ./../../libltdl/libltdlc.la | sed 
's,.*\.\./libltdl/,,g'`)
| make[6]: Entering directory `/tmp/libtool/build-x86_64/libltdl'
| make[6]: *** No rule to make target `libltdlc.la'.  Stop.


Your libtoolize tests all fail (1, 2, 3) because you changed `copying'
to `linking' (why not say `linking' only if that is what you do, i.e.
without `--copy'?)

Somehow the test suite was not automagically updated to include
`standalone'.  I believe this might have been my fault.

There exists $top_builddir/.deps with files "argz.Plo lt__dirent.Plo
lt__strl.Plo" now.  I don't know whether this is a bug (believe not).

The files
  libltdl/Makefile{,.am,.in}
          configure{,.ac}
          aclocal.m4
          README
          config-h.in
          m4/lt~obsolete.m4

are not shipped in libtool-2.1.tar.gz, and a subsequent
  configure
  make
from the tarball does not create any of them (it should create Makefile,
and everything else should be shipped, right?).

I don't really like config and m4 below libltdl.  It seems ugly.
But that is a minor issue.

I stopped further testing after this.  It would be nice if your
standalone tests could run a `make distcheck' so we can be reasonably
sure `libltdl/Makefile.am' has everything it needs.  Once for
AC_LIBLTDL_CONVENIENCE and once for AC_LIBLTDL_INSTALLABLE.

It would also be nice (while I'm at the point of using old macro names)
to test whether using the old names works.  That is exactly what all
upgraders will hit first when going to 2.0.


As I am a fan of "one change per patch", I'd have liked to have the
- use of auxdir, m4dir
- move files around
- update all dependents, simplify libtoolize
- change `copying' to `linking'
- build libltdl from $top_builddir/Makefile

as separate patches, they would have been easier to verify (the first
two separated only because of CVS limitations -- it's almost impossible
to trace back using `cvs annotate' if you change a file while moving at
the same time).  But you don't have to start doing that now, it's not
worth the amount of work.

By the way, have you ever tried `make installcheck' with the new
testsuite?

How do you expect a backport to be able to work when bootstrapped with
released autoconf/automake?  IOW: what exactly do you want to backport?

Regards,
Ralf

>       Reorganise the libtool tree to create a bootstrapped libltdl for
>       installation to the libtoolize master tree, so that libltdl is
>       useable even in the extreme case of when automake and autoconf are
>       not installed on the developers machine.  Part of this change
>       requires some duplication of rules between Makefile.am (which
>       builds libltdl for this distribution) and libltdl/Makefile.am
>       (which is used by projects that libltoolize --ltdl --copy), so
>       libtool now really does use a single toplevel Makefile.am, and we
>       generate libltdl/Makefile.am from that:
> 
>       * m4, config: Moved from here...
>       * libltdl/m4, libltdl/config: ...to here, to reduce the amount of
>       kludging needed in bootstrap for autoreconf to run.
>       * libltdl/m4/ltdl.m4: Increment serial number.
>       (LTDL_INIT): Accept an optional directory argument to prefix each
>       of the LD_DLLOADERS locations.  Default to empty for backwards
>       compatibility.
>       * Makefile.maint: Adjust to compensate.
>       * configure.ac (AC_CONFIG_AUX_DIR, AC_CONFIG_MACRO_DIR): Adjust.
>       (AC_CONFIG_LIBOBJ_DIR): Set here so that we can build LTLIBOBJS
>       from in a subdirectory from the amalgamated Makefile.am.
>       (AM_PROG_CC_C_O, AM_INIT_AUTOMAKE): Use subdir-objects.
>       (AC_CONFIG_FILES): Remove libltdl/Makefile.am.
>       * libltdl/Makefile.am: Removed from repository, and merged into
>       Makefile.am as we now generate it...
>       * Makefile.am (libltdl/Makefile.am): ...from here, by extracting
>       the merged rules, and tweaking paths to accomodate the difference
>       in directory from Makefile.am to libltdl/Makefile.am.
>       (nobase_dist_pkgdata_DATA): Automake generated installation rules
>       change timestamps of installed files, so renamed this...
>       (configauxfiles): ...to this...
>       (libtoolize): ...substitute it...
>       (install-data-local): ...install manually, preserving
>       timestamps...
>       (install-data-hook): ...and set execute bit as appropriate.
>       (libltdl/Makefile.in): New rule.  Called from...
>       * bootstrap: ...here to avoid relying on config.status at
>       bootstrap time.
>       (auxdir, m4dir): Extract from configure.ac for ease of future
>       maintenance.  Adjust all references.
>       (reconfdirs): Call autoreconf for libltdl too -- even
>       though we don't use it for the build, libltdl/configure and
>       friends are installed with `libtoolize --ltdl --copy'.
>       * libtoolize.m4sh: Add files from the installed config master tree
>       to libtoolize --ltdl project subdirectory.
>       Diagnose duplicated files when --ltdl is used in an autotooled
>       project.
>       It's perfectly fine to run `libtoolize --ltdl --copy' in a tree
>       that has no configure.ac or configure.in; we want libltdl to be
>       useful even to projects that don't use autotools themselves.
>       (libtoolize_flags): Removed.  Changed all callers.
>       (func_massage_pkgconfig_files): New function.
>       * tests/standalone.at: New tests for using libltdl without
>       supporting configury in the parent project.
>       * tests/testsuite.at: Run them!




reply via email to

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