Re: bug#19108: bad error messages in dist targets, automake 1.14.1
Hi Stefano, On 19 Dec 2014, at 10:12, Stefano Lattarini stefano.lattar...@gmail.com wrote: severity 19108 minor close 19108 thanks On 11/19/2014 05:40 PM, Aharon Robbins wrote: Hi. I'm trying to upgrade to automake 1.14.1, and I see this: @@ -993,10 +993,16 @@ dist-xz: distdir $(am__post_remove_distdir) dist-tarZ: distdir +@echo WARNING: Support for shar distribution archives is \ + deprecated. 2 +@echo WARNING: It will be removed altogether in Automake 2.0 2 tardir=$(distdir) $(am__tar) | compress -c $(distdir).tar.Z $(am__post_remove_distdir) dist-shar: distdir +@echo WARNING: Support for distribution archives compressed with \ + legacy program 'compress' is deprecated. 2 +@echo WARNING: It will be removed altogether in Automake 2.0 2 shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).shar.gz $(am__post_remove_distdir) The error messages are associated with the wrong targets. I thought I reported this already... Thanks, Arnold Thank for the report. I've applied a fix that will appear in the next automake release. 0001-dist-adjust-warning-messages-about-shar-and-tarZ-dep.patch It looks like the warning content for those two targets are reversed to me... Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: How to remove all newly generated files in amhello?
[Moved to Automake List] On Jul 31, 2013, at 8:00 AM, Peng Yu pengyu...@gmail.com wrote: On Tue, Jul 30, 2013 at 7:25 PM, Gary V. Vaughan g...@vaughan.pe wrote: On Jul 31, 2013, at 5:15 AM, Peng Yu pengyu...@gmail.com wrote: http://www.gnu.org/software/automake/manual/html_node/Creating-amhello.html I followed the above instructions to create amhello. After running `autoreconf -i` and `make`, it generated a lot of files. I tried to remove all newly generated files by `make distclean`. But this did not remove all the newly generated files. Could anybody let me know how to remove the newly generated files? Thanks. $ make maintainer-clean No. if maintainer-clean is not removing files that were generated by running make; then MAINTAINERCLEANFILES is not set up properly, add the unexpected file droppings with: MAINTAINERCLEANFILES = list of make generated files for maintainer cleanup else if maintainer-clean is not removing files that you created by other means; then that is to be expected - how can Automake know where they came from, and whether you want them removed or not? else if you are feeling especially brave; then you can list just the files you want to keep and nuke the rest with a custom rule: ## untested, so make sure you have a backup if you intend to actually run this! MYPRECIOUSFILES = list of files not to remove .PHONY: nuke nuke: for file in `find . -type f -print`; do \ case ' $(MYPRECIOUSFILES) ' in \ * $$file *) ;; \ *) rm -f $$file ;; \ esac; \ done else if you put the project in git; then you can remove all the non-version controlled files with: $ git clean -dfx else exit 1 fi # ;) HTH, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Hi Stefano, Nick,
On Oct 18, 2012, at 4:04 PM, Stefano Lattarini stefano.lattar...@gmail.com
wrote:
On 10/17/2012 10:05 PM, Nick Bowler wrote:
On 2012-10-17 09:25 +0200, Stefano Lattarini wrote:
On 10/16/2012 10:46 PM, Nick Bowler wrote:
I think it's important to have, for testing, a version of aclocal that
actually makes use of this feature.
The reason I wrote this patch is because I want to make use of this
feature in aclocal 1.13. See also:
http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00030.html
Right, I didn't mean to suggest that you weren't planning to use it:
what I'd like to see is
* a patch to autoconf (we have this: currently under discussion)
* a patch to aclocal
* a patch to libtoolize
so that people (like me) can apply all these patches, try to convert
their projects to use AC_CONFIG_MACRO_DIRS, and actually see how things
behave first hand. The linked aclocal patches don't seem like they'd
work with *this* autoconf patch under discussion.
Of course, they were written before these autoconf patches :-)
Anyway, I agree some early testing by real users would be very useful,
so here is a first cut at the Automake part of the AC_CONFIG_MACRO_DIRS
support (see attached patches).
Similarly, I've enhanced libtoolize to give priority to AC_CONFIG_MACRO_DIRS,
and (for continued backward compatibility with less-than-bleeding-edge aclocal
and Autoconf) falling back to AC_CONFIG_MACRO_DIR and finally
ACLOCAL_AMFLAGS when determining where to install it's m4 macros.
You can fetch it from current git master:
$ git clone git://git.savannah.gnu.org/libtool.git libtool--savannah
$ cd libtool--savannah
$ git checkout master
$ ./bootstrap ./configure --prefix=/path/to/test/tree make all check
The recommendations to use ACLOCAL_AMFLAGS are still emitted by this
revision until there is a released aclocal that works without, at which point
I'll patch it again so that it only continues to give out that recommendation
if the installed aclocal (or binary pointed to by ACLOCAL) is an old enough
version that it's still required.
Shortly after the next release, I'm planning to split the libtool project into
two:
1. libtool.m4/ltmain.sh + support
2. libltdl + support
At that point aclocal will take care of libtool.m4, and libltdl will no longer
support being embedded into a project source tree, so libtoolize will be little
more than:
#!/bin/sh
pkgdatadir=/usr/local/share/libtool
aux_dir=`$pkgdatadir/extract-trace AC_CONFIG_AUX_DIR |sed 1q`
cp $pkgdatadir/ltmain.sh ${aux_dir-.}
Let me know if I missed anything :)
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake
Hello Mr. Strike, On Oct 18, 2012, at 7:16 PM, NightStrike nightstr...@gmail.com wrote: On Wed, Oct 17, 2012 at 11:27 AM, Gary V. Vaughan g...@gnu.org wrote: Thanks to everyone for your feedback. Much appreciated. It seems that merging libtool into Automake would be an unpopular move all around, with significant downsides for users, so I no longer plan to do that... unless there is a still strong technical argument supporting it that I've yet to hear. One guy and one day isn't really all around. You should solicit a bit more feedback (unless there's a bunch of messages that aren't cross posted to the automake list, so I missed them..) I, for one, think it's a great idea. When the guy currently in charge of Automake says no, that really does mean no. And, his argument is good in any case, so I'm inclined to agree, at least for now. However, that doesn't mean we're not happy to hear the technical argument in support of moving libtool inside Automake. I won't be tackling the actual implementation of the split for at least a few more weeks, so you still have time to talk us around ;) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [RFC] Superseding aclocal? (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal)
Hi Stefano,
Thanks for the fast response!
On 17 Oct 2012, at 15:52, Stefano Lattarini stefano.lattar...@gmail.com wrote:
[Adding Automake list in CC:]
Reference:
https://lists.gnu.org/archive/html/autoconf-patches/2012-10/msg00018.html
On 10/17/2012 10:25 AM, Gary V. Vaughan wrote:
[SNIP]
I remember many years ago that Tom Tromey (IIRC) stated that aclocal
was just a stop-gap measure until autoconf could find it's own macros.
I'd *really* like to see aclocal die as a separate program, and have
autoconf look for (and if requested, copy into the project tree) all the .m4
files it needs to generate a configure script.
Me too... But aclocal has existed and been used for so many years now that
I think we can't just make it disappear overnight; we'd need a carefully
crafted, documented and publicized transition plan. A fist step might be
to move aclocal out into its own git repository, while still distributing
it bundled with Automake (this could be done for Automake 1.14). But before
starting even to plan for that move, I'd want to be sure that the intended
replacement is well underway (that is, designed, agreed upon, and with at
least a semi-working prototype), and that the community is happy with this
transition and committed to help it.
I think there is no need for such a cumbersome transition. Instead, I would
do it like this:
1. Fold macro search/copy code into autoconf (along with -I argument support)
2. Reimplement aclocal as a wrapper to call autoconf
Tools that still use aclocal can do so harmlessly while it is deprecated,
but in the mean time everyone can begin to move to a more streamlined build
that simply skips the aclocal step.
No need even for aclocal.m4
in that case anymore... the fewer files and tools we have to teach people
about, the less baroque those people will feel that the Autotools are, and
the easier the GBS is to understand and learn.
Honestly, AFAICS, few people complained about aclocal so far (which sadly
can't be said for automake and autoconf). So aclocal might be annoying for
us to maintain, but doesn't seem a real burden for the users.
Most likely because the folks that complain can't distinguish between
where aclocal ends and automake/autoconf begins ;)
I'd have written patches myself long ago, but sadly, Autoconf moved its
implementation to Perl before I had time to do it :(
I honestly believe having an implementation of autom4te, aclocal or automake
in portable shell scripting would be insane. Perl is much, much safer and
easier to use for such moderately big programs. Not to mention more
efficient, especially for platforms with expensive fork() like Cygwin.
Agreed. Perl was a good choice at the time.
I meant unfortunate for me, since after two failed attempts comprising several
painful readings of the Camel and Llama books, I finally gave up trying to
understand Perl over a decade ago. If it were in a language that made sense to
me, I'd have written the patches already. I can sorta kinda still hit Perl code
with a hammer, and make it work, but it would be as unreadable to everyone
else, as other Perl code is to me.
-- And unfortunate for whoever writes the perl patches, since I didn't do it
for them ;)
At least I can help with the design a bit...
Here's a minimal modernish bootstrap script:
#!/bin/sh
autopoint --force
libtoolize --copy --install
aclocal # m4 dir from ACLOCAL_AMFLAGS
autoconf
autoheader
automake --add-missing --copy
With aclocal search and copy rolled into autoconf, it could look the same,
or else like this:
#!/bin/sh
autopoint --force
libtoolize --copy --install
autoconf # m4 dir from AC_CONFIG_MACRO_DIR{,S}
autoheader
automake --add-missing --copy
OFF-TOPIC
If autoreconf were smarter about autopoint and libtoolize ordering, it might
even be possible to fold much of the bootstrap script nonsense back into
autoreconf, but that's a discussion for another day.
/OFF-TOPIC
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
[RFC] Moving ltmain.sh and libtool.m4 into Automake
Autotoolers, For quite some time now I've been thinking about simplifying Libtool, but I'm interested in feedback and more particularly buy-in from Automake maintainers before I start the work, so that I have a better idea of what direction I'm heading in... Libtool is just (a complicated) compiler wrapper, to make building and linking against libraries easy to specify... be that on the command line with a direct libtool invocation, or from Makefile.am specifications. I'm considering splitting the current libtool project in two: 1. libltdl as a standalone runtime loader wrapper 2. libtool.m4/ltmain.sh to generate the libtool script I think (2) belongs better into Automake alongside the other tool wrappers it already carries, where it can decide whether to run the libtool m4 macros and roll an appropriate compiler wrapper tailored for the project using it (no need for all the C++/Java/Fortran goo in a C- only project for example). Another consideration is that rolling Libtool into Automake would make using Libtool as a standalone script rather more difficult. Having said that, my impression is that Libtool is rarely used that way in any case, and further simplification may be possible by deliberately dropping explicit support for that use case. If I make this split and contribute the macros and ltmain.sh to Automake, is this something anyone else would like? If so, do you like it enough to wire it into Automake with an appropriate hunk of Perl? If the consensus is that Automake is not a good home for the libtool compiler wrapper, then I still plan to split Libtool into two projects as outlined above to decouple and simplify somewhat -- although I have some other things to attend to first, so it will not happen right away, but more likely after the next release. Thoughts? Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [RFC] Superseding aclocal?
Hi Stefano,
On 17 Oct 2012, at 16:45, Stefano Lattarini stefano.lattar...@gmail.com wrote:
On 10/17/2012 11:24 AM, Gary V. Vaughan wrote:
On 17 Oct 2012, at 15:52, Stefano Lattarini stefano.lattar...@gmail.com
wrote:
On 10/17/2012 10:25 AM, Gary V. Vaughan wrote:
I remember many years ago that Tom Tromey (IIRC) stated that aclocal
was just a stop-gap measure until autoconf could find it's own macros.
I'd *really* like to see aclocal die as a separate program, and have
autoconf look for (and if requested, copy into the project tree) all the
.m4
files it needs to generate a configure script.
Me too... But aclocal has existed and been used for so many years now that
I think we can't just make it disappear overnight; we'd need a carefully
crafted, documented and publicized transition plan. A fist step might be
to move aclocal out into its own git repository, while still distributing
it bundled with Automake (this could be done for Automake 1.14). But before
starting even to plan for that move, I'd want to be sure that the intended
replacement is well underway (that is, designed, agreed upon, and with at
least a semi-working prototype), and that the community is happy with this
transition and committed to help it.
I think there is no need for such a cumbersome transition. Instead, I would
do it like this:
1. Fold macro search/copy code into autoconf (along with -I argument
support)
So autoconf should generate aclocal.m4 itself? That seems subotimal.
No. If autoconf can find it's own macros, then there's no need to copy them
(or m4_include them) into aclocal.m4, which is just an historical implementation
detail of pre-2.13 autoconf... it will just load the macro definitions from
wherever it finds them, and (optionally) copy them into AC_CONFIG_MACRO_DIR{,S}
for distribution.
Back in the day, it was easier for Tom to write aclocal inside Automake, which
he already maintained and have it copy all the macro implementations that
Autoconf would need into a file that the existing implementation already reads.
I'd
rather see a clean design in autoconf or even m4 (so done without having to
worry about backward-compatibility); once that is deployed and working, we
could separate aclocal from automake, declare it obsolescent, but keep it
around for backward-compatibility (once we say this package will no longer
be updated, it stops being a maintenance burden, so we could keep it around
indefinitely, as long as people want to use it).
That's true, but orthogonal to teaching autoconf to find macros directly rather
than looking only in aclocal.m4 and having a separate tool to copy stuff there
first.
Honestly, AFAICS, few people complained about aclocal so far (which sadly
can't be said for automake and autoconf). So aclocal might be annoying for
us to maintain, but doesn't seem a real burden for the users.
Most likely because the folks that complain can't distinguish between
where aclocal ends and automake/autoconf begins ;)
While that is true, what I meant is that they report issues that have to
due with their interfacing with autoconf and automake (suboptimal or
unclear syntax, m4 quoting problems, unclear error messages, backward
compatibility issues) far more often than they report issues having to
do with aclocal. Which means that aclocal is fulfilling its role quite
well; and although we developers would prefer such a role not to even
exist, that doesn't concern the users very much IMVHO.
ACK.
Here's a minimal modernish bootstrap script:
#!/bin/sh
autopoint --force
libtoolize --copy --install
aclocal # m4 dir from ACLOCAL_AMFLAGS
autoconf
autoheader
automake --add-missing --copy
With aclocal search and copy rolled into autoconf, it could look the same,
or else like this:
#!/bin/sh
autopoint --force
libtoolize --copy --install
autoconf # m4 dir from AC_CONFIG_MACRO_DIR{,S}
Then we'd at least need a way to emulate aclocal --install in autoconf,
since having third-party macro definitions distributed for a more reliable
and predictable build is a feature several users want, independently from
its implementation details (that is, whether such a feature is offered
by aclocal or autoconf). And we'd also need to have ACLOCAL_PATH (or an
equivalent functionality) supported by autoconf ...
Good point.
It looks like the functionality needs to be split between Autoconf and
Automake, since the files that `aclocal --install` copies are partly for
autoconf,
and partly for the rules Automake writes for make. Since the two projects
already share some infrastructure, I don't see a problem in having both tools
capable of installing support scripts that they require.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake
Thanks to everyone for your feedback. Much appreciated. It seems that merging libtool into Automake would be an unpopular move all around, with significant downsides for users, so I no longer plan to do that... unless there is a still strong technical argument supporting it that I've yet to hear. On 17 Oct 2012, at 20:57, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Wed, 17 Oct 2012, Gary V. Vaughan wrote: Libtool is just (a complicated) compiler wrapper, to make building and linking against libraries easy to specify... be that on the command line with a direct libtool invocation, or from Makefile.am specifications. I'm considering splitting the current libtool project in two: 1. libltdl as a standalone runtime loader wrapper If it helps any with decision making, on October 15th I unbundled libltdl from GraphicsMagick, twelve years after I originally bundled it into ImageMagick. I decided to do this because I realized that the value added by the bundling did not exceed the potential harm caused by the bundling. Project configure and build times improved by removing libltdl. It does help, and in fact your observations about all the linking and duplication issues (which Thomas Tanner glossed over in the docs to be left as an exercise for the reader) crystalised my partly formed ideas about the benefits of a split. I do plan to split the two shortly after the next libtool release. Creading a stand-alone libltdl package is a very good idea. The separation will also make both packages much smaller and more manageable, especially without all the contortions of trying to support all the different ways of copying everything into the parent package that libltdl currently supports. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
bug#11863: Building test plugins
Hi Reuben, On 5 Jul 2012, at 05:39, Reuben Thomas wrote: On 4 July 2012 23:35, Stefano Lattarini stefano.lattar...@gmail.com wrote: tags 11863 + moreinfo thanks On 07/04/2012 10:43 PM, Reuben Thomas wrote: I have a library that I want to build just for tests. Hence, I add it to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or whatever) to be built, but it isn't! It isn't built when you run make check? The library is built, but no .so. check_LTLIBRARIES works somewhat like noinst_LTLIBRARIES, in that Automake instructs libtool to build a convenience archive by default in both cases (a convenience archive being a static archive of pic objects). Arguably that's not the right thing for check_LTLIBRARIES, for exactly the reasons you have been tripped up by here. And I'd be in favour of changing the semantics of check_LTLIBRARIES accordingly - libltdl based module loaders will continue to cope just fine because the .la file is examined to determine how to link and load the module. Currently the best way to tell Automake to only build a libtool library for `make check' without installing it, but at the same time to tell libtool not to make a convenience archive is: check_LTLIBRARIES += tests/libalientest.la tests_libalientest_la_LDFLAGS = -module -avoid-version -rpath /dev/null The -rpath argument tells libtool that this is not a convenience archive. The parameter can be anything, because Automake will not install a check_LTLIBRARIES object anyway, but /dev/null makes it clearer that we'r doing something a bit odd here. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
Hi Stefano, Eric, On 17 Nov 2011, at 00:27, Stefano Lattarini wrote: On Wednesday 16 November 2011, Eric Blake wrote: + - At some point we were supporting some undetermined `broken make', as +evidenced by having carried the following code since 2003: + + ## use @LIBLTDL@ because some broken makes do not accept macros in + ## targets, we can only do this because our LIBLTDL does not contain + ## $(top_builddir) + @LIBLTDL@: $(top_distdir)/libtool \ + ... By the way, such make implementations (that don't work with $(macros) in targets) exist: https://lists.gnu.org/archive/html/automake-patches/2008-12/msg00027.html This links says nothing about make not accepting macros in targets; it says that using macros on the left side of a *macro assignment* is not portable: # Bad, not portable. foo$(var) = bar # But this should be OK. foo$(var): @echo crating $@. Right, and even when I wrote the dubious comment quoted above in 2003, other parts of libtool were still using macro expansions in make targets, so I think the whole thing is probably a red herring. Libtool has never fully supported any make that can't deal with macros in targets, and we've never received a complaint or bug report, which makes me think that if such a make exists, no one wants to use it with libtool, so we can safely ignore the whole thing. The NEWS entry I wrote for this commit is purely for future repo archaeology. At least IRIX and HP-UX vendor make fail to handle macros in the target. Are you sure? I'm seeing this in the master branch of automake: $ grep -C1 '^$(.*) *:' lib/am/*.am lib/am/check.am- lib/am/check.am:$(TEST_SUITE_LOG): $(TEST_LOGS) lib/am/check.am-@$(am__sh_e_setup); \ -- lib/am/configure.am-if %?REGEN-ACLOCAL-M4% lib/am/configure.am:$(ACLOCAL_M4): %MAINTAINER-MODE% $(am__aclocal_m4_deps) lib/am/configure.am-?TOPDIR_P? $(am__cd) $(srcdir) $(ACLOCAL) $(ACLOCAL_AMFLAGS) -- lib/am/configure.am-## Avoid the deleted header file problem for the dependencies. lib/am/configure.am:$(am__aclocal_m4_deps): lib/am/configure.am-endif %?REGEN-ACLOCAL-M4% -- lib/am/lisp.am-## an empty target. lib/am/lisp.am:$(am__ELCFILES): elc-stamp lib/am/lisp.am-## Recover from the removal of $@. -- lib/am/subdirs.am- lib/am/subdirs.am:$(RECURSIVE_TARGETS): lib/am/subdirs.am-## Using $failcom allows -k to keep its natural meaning when running a -- lib/am/subdirs.am-## bombs. lib/am/subdirs.am:$(RECURSIVE_CLEAN_TARGETS): lib/am/subdirs.am-## Using $failcom allows -k to keep its natural meaning when running a ... but Ralf Wildnehues used to test automake somewhat regularly on both IRIX and HP-UX, and to my knowledge never reported an error related to the contructs above. + +However, we've also had *many* cases of macros in targets for just as +long, so most likely we never fully supported makes allegedly broken +in this way. As of this release, we explicitly no longer support +make implementations that do not accept macros in targets. I suppose we can resuscitate make portability if anyone complains loudly enough. We may want to also ask on the automake list if this is still a real limitation, or whether automake has given up on worrying about this as well. See above. When my Internet comes back reliably and I can do more than just put mail in qmail's queue for the next time I have a bit of bandwidth, I'll make sure to test the HEAD of libtool master on the architectures I have access to, including both HP/UX and IRIX. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: need to set ACLOCAL_AMFLAGS along with AC_CONFIG_MACRO_DIR
On 16 Sep 2010, at 03:11, Eric Blake wrote: At any rate, it seems like maintaining ACLOCAL_AMFLAGS in Makefile.am is redundant - how hard is it to teach automake to have aclocal _automatically_ include directories mentioned inside AC_CONFIG_MACRO_DIR, to avoid the dual file maintenance headache? I have proposed this a couple of times over the years, and would have submitted a patch long ago if I hated perl less ;o) To avoid any surprises, I think the trick is to simply have autoreconf fall back to reading AC_CONFIG_MACRO_DIR where there is no conflicting ACLOCAL_AMFLAGS in Makefile.am. Libtoolize users will have fewer issues here though, because libtoolize already complains about conflicts between AC_CONFIG_MACRO_DIR and ACLOCAL_AMFLAGS. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: Defining dependencies in Automake
[please delete autoc...@gnu.org from Cc: if you reply] This is really an automake question, so you posted to the wrong list! On 22 Jun 2010, at 22:32, Sam Silla wrote: Greetings, I have a Makefile.am file right now that looks like this: lib_LIBRARIES = foo.a foo_a_SOURCES = bar.F90 baz.F90 However, bar.F90 depends on several other Fortran files (x.F90, y.F90, z.F90). I would like to set up Automake to rebuild bar.o if the source of one of these dependencies change. I've been reading the GNU manuals for automake/autoconf and was unable to find an applicable solution to this. Thanks for reading. Remember that Makefile.am is just a Makefile, and that automake copies any rules you add to Makefile.am into Makefile. If bar.F90 somehow includes the contents of the other source files: EXTRA_SOURCES = x.F90 y.F90 z.F90 bar.o: bar.F90 x.F90 y.F90 z.F90 Or if bar.o is made from partially linked objects (I'm not a fortran programmer, so I don't know how the fortran compiler links): bar.o: x.o y.o z.o If you have several dependencies in the form of either of the above, you also might want to look into storing the dependencies in make variables. HTH, -- Gary V. Vaughan (g...@gnu.org)
334-gary-remove-libtool-dvi.patch
[[FYI: bug-automake]] I suspect this also exposes a bug in non-recursive automake with subdir-objects, since I would have expected libtool.dvi to end up in the doc subdirectory... and so does our Makefile.in, which contains several references to doc/libtool.dvi. Regardless, without this patch, make distcheck always fails because it finds ./libtool.dvi after running make distclean in the unpacked tarball tree. So, we need this at least until automake is fixed. Okay to commit? Index: ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * Makefile.am (DISTCLEANFILES): Remove libtool.dvi generated by 'make dvi'. Index: Makefile.am === RCS file: /sources/libtool/libtool/Makefile.am,v retrieving revision 1.228 diff -u -u -r1.228 Makefile.am --- Makefile.am 6 Jan 2008 16:33:30 - 1.228 +++ Makefile.am 18 Jan 2008 09:31:54 - @@ -319,6 +319,10 @@ info_TEXINFOS= doc/libtool.texi doc_libtool_TEXINFOS = doc/PLATFORMS doc/fdl.texi doc/notes.texi EXTRA_DIST += $(srcdir)/doc/notes.txt +## Automake provides the rules to generate this, and should probably +## be responsible for cleaning it up... in the meanwhile, if we don't +## remove it ourselves, distcheck will fail: +DISTCLEANFILES += libtool.dvi all-local: $(srcdir)/doc/notes.txt Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: [AM-1.4] make distclean tries to build objects
Hi Daniel, Daniel Haude wrote: What can one say about this? I don't get it. Thanks, --Daniel [EMAIL PROTECTED]:~/Projects/ctops$ make distclean Making distclean in . make[1]: Entering directory `/home/dh/Projects/ctops' rm -f config.h rm -f TAGS ID rm -f Makefile rm -f config.cache config.log stamp-h stamp-h[0-9]* make[1]: Leaving directory `/home/dh/Projects/ctops' Making distclean in gui make[1]: Entering directory `/home/dh/Projects/ctops/gui' gcc -DHAVE_CONFIG_H -I. -I. -I.. -DPACKAGE_DATA_DIR=\/usr/local/share\ -DPACKAGE_LOCALE_DIR=\/usr/local//locale\-DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../tops -W -Wall -ansi -pedantic -g -g -O2 -c refine.c In file included from refine.c:7: support.h:6:22: config.h: No such file or directory make[1]: *** [refine.o] Error 1 make[1]: Leaving directory `/home/dh/Projects/ctops/gui' make: *** [distclean-recursive] Error 1 [EMAIL PROTECTED]:~/Projects/ctops$ [EMAIL PROTECTED] From automake.info(Recursing subdirectories); By default, Automake generates `Makefiles' which work depth-first (`postfix'). However, it is possible to change this ordering. You can do this by putting `.' into `SUBDIRS'. For instance, putting `.' first will cause a `prefix' ordering of directories. All `clean' targets are run in reverse order of build targets. I don't recall whether ancient automake supports the `.' option in SUBDIRS. Probably not. You are fighting against all the bugs and misfeatures that have been fixed over the last five years of automake development if you insist on staying with automake-1.4 (I branched for the 1.4px series in early 2001). HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: specifying target directories in non-recursive automake
John Darrington wrote: I've been trying to convert a rather largish automake controlled project from a recursive style build system, to a non-recursive one. I was rather suprised to see that automake decides to put all the object files in the root directory; not only ugly, but destroys the namespaces afforded by each directory. Consequently, things are falling down when in the cases where there are identically names source files in different directories. For example, this simple Makefile.am complains about main.o being created twice, when the two main.c files are clearly separate. bin_PROGRAMS = prog1/foo prog2/bar prog1_foo_SOURCES = prog1/main.c prog2_bar_SOURCES = prog2/main.c Reading the manual suggests that I should be able to prefix the SOURCES variables with nobase_ but it doesn't seem to work. Can anyone tell me the correct way to create a non-recursive automake system, which might have identically named source files? In your configure.ac, make sure AM_INIT_AUTOMAKE is given the subdir-objects option (you'll also need a recent automake): AM_INIT_AUTOMAKE([1.9 subdir-objects]) HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: Newbie: Installing some binaries and other files in /usr/X11R6 by default
[EMAIL PROTECTED] wrote: I started reading about GNU Autotools yesterday morning. Still, I've been able to convert my project to use autconf and automake. But I need to install my binaries in the directory tree of the X server, and I couldn't find out how to do it. Is it possible? $ ../path/to/configure --prefix=/path/to/X11R6/root/directory $ make $ su # make install HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: A extremely simple exaple on how to use automake to build libs
[EMAIL PROTECTED] wrote: Many thanks. There is one problem though: the example convenience-1.0 doesn't work! configure: creating ./config.status config.status: creating replace/Makefile config.status: creating lib/Makefile config.status: creating Makefile config.status: error: cannot find input file: Makefile.in You have 2 problems: i) you forgot to run the bootstrap script to run the autotools ii) the book was written with autoconf-2.13, automake-1.4-p5 and libtool-1.4.2... almost entirely different to what you are using. I've just update the links from http://sources.redhat.com/autobook/download.html to give the option of downloading a modernised version of some of the examples, including a new convenience-2.0. Please give it a try. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: Fwd: Automake problem: one makefile for everything
[Please remove libtool@gnu.org from replies to this thread] [EMAIL PROTECTED] wrote: Hi, I hope you can help me. I'm banging my head against the wall here doing something that I think should be extremely simple, but just cannot get Automake/Autoconf/libtool to do it the way I want it. If I have the following files: main1.c main2.c modules/mod1.c modules/mod2.c and I want a Makefile.am in the top-level source directory that compiles main1.c and main2.c into one library (say libmain.la) and mod1.c and mod2.c into libmod.la in the modules directory. Simple request huh? But in *one* Makefile.am. How do I do it? AUTOMAKE_OPTIONS = subdir-objects lib_LTLIBRARIES = libmain.la modules/libmod.la libmain_la_SOURCES = main1.c main2.c modules_libmod_la_SOURCES = modules/mod1.c modules/mod2.c HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: symlinked libltdl and aclocal
Hallo Ralf, Ralf Wildenhues wrote: Symlinking libltdl into a project (as in) libtoolize --ltdl is pretty stupid when later on aclocal decides it needs to run in libltdl/ -- it'll try to write in the aclocal.m4 file that can be reached through the symlink, instead of removing the symlink before writing. This may happen in the non-subpackage case (whenever that'll work), but I believe it can also trigger when AC_CONFIG_MACRO_DIR is shared between the packages. Bug in aclocal? I think so. Oooh. Nice catch! For compatibility with older aclocal, I guess we need to work around that by having libtoolize always copy aclocal.m4 with --ltdl, even if --copy wasn't specified? :-/ Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: [PATCH PING] Support AC_CONFIG_LIBOBJ_DIR (fixes PR/401)
It's been a couple of weeks since there was any movement on this
thread... just a gentle reminder that the automake section is still
awaiting attention.
Cheers,
Gary.
Gary V. Vaughan wrote:
Salut Alexandre,
Thanks for the feedback:
Alexandre Duret-Lutz wrote:
* LIBOBJDIR seems worthy to document from the Autoconf user perspective.
Non-automake might also benefit from this; and we should avoid using
undocumented interfaces in Automake.
Okay, I've added that to the attached revision of this patch.
* The comment in _AC_LIBOBJS_NORMALIZE seems misleading to me,
because LIBOBJDIR is unrelated to the macro
AC_CONFIG_LIBOBJ_DIR as far as Autoconf is concerned.
AC_CONFIG_LIBOBJ_DIR specifies where the *sources* files are.
LIBOBJDIR is a prefix variable the user cano use to relocate
the *object* files. This is not necessary the same place.
True enough also. I've changed the comments to describe the situation more
accurately.
* Autoconf needs to be adjusted to reflect the fact that
Automake scans a new macro. See the comment above the %traced
variable you modified in scan_autoconf_trace.
AC_CONFIG_LIBOBJ_DIR is already there in autoconf-2.59 and HEAD.
* Better write ${LIBOBJDIR} instead of $(LIBOBJDIR) in @LIBOBJS@
(for the same reason we use ${prefix}, etc.)
I disagree, LIBOBJDIR is a make macro not a shell variable, so it is more akin
to $(srcdir) than ${prefix}. If I'm missing something, feel free to change it
before committing.
* The Automake manual should be updated at least in two places:
- the place where it documents all the macros that can
affect its behavior (your patch causes
AC_CONFIG_LIBOBJ_DIR to have a stronger semantic when used
with Automake than when used with only Autoconf).
- the section about how LIBOBJS is used.
* Use $PERL, not perl.
Both done. Thanks for the pointers.
* AFAICT your patch assumes that users use option `subdir-objects' when
using @LIBOBJS@ remotely. I think we should also support the other case.
I suggest you don't bother with the last point unless it looks
easy to you. I'll probably find some time this week-end or next
week.
Agreed on all counts. My perl-fu is as always insufficient to the task,
thanks for offering to do the rest.
ChangeLog entries for automake:
2005-04-25 Gary V. Vaughan [EMAIL PROTECTED]
Fixes PR/401
* automake.in (config_libobj_dir): Either `.' or whatever directory is
given to AC_CONFIG_LIBOBJ_DIR in configure.ac.
(scan_autoconf_traces): Set config_libobj_dir.
(sub_read_am_file): Define LIBOBJDIR according to relative path from
each Makefile to AC_CONFIG_LIBOBJ_DIR directory.
(require_libobj_with_macro): Use $config_libobj_dir when looking for
LIBOBJs.
(handle_LIBOBJS, handle_ALLOCA): Use it.
* tests/Makefile.am (TESTS): Declare pr401.test.
* tests/pr401.test: New test.
* doc/automake.texi (LIBOBJS): Document changes in behaviour of
LIBOBJS, ALLOCA, LTLIBOBJS LTALLOCA in the presence of
subdir-objects and an invocation of AC_CONFIG_LIBOBJ_DIR.
And autoconf:
2004-04-20 Gary V. Vaughan [EMAIL PROTECTED]
* lib/autoconf/general.m4 (_AC_LIBOBJS_NORMALIZE): Prepend each object
named in LIBOBJS and LTLIBOBJS with the $(LIBOBJDIR), as set by latest
automake.
Cheers,
Gary.
--- automake.in.orig 2005-02-12 10:06:56.0 +
+++ automake.in 2005-04-20 14:08:05.0 +0100
@@ -142,6 +142,7 @@
use Automake::RuleDef;
use Automake::Wrap 'makefile_wrap';
use File::Basename;
+use File::Spec;
use Carp;
## --- ##
@@ -333,6 +334,10 @@
# in Makefiles.
my $am_config_aux_dir = '';
+# Directory to search for AC_LIBSOURCE file, as set by AC_CONFIG_LIBOBJ_DIR
+# in configure.ac.
+my $config_libobj_dir = '';
+
# Whether AM_GNU_GETTEXT has been seen in configure.ac.
my $seen_gettext = 0;
# Whether AM_GNU_GETTEXT([external]) is used.
@@ -2067,7 +2072,7 @@
if ($iter =~ /\.h$/)
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
elsif ($iter ne 'alloca.c')
{
@@ -2079,7 +2084,7 @@
my $bs = var ('BUILT_SOURCES');
if (! $bs || ! grep (/$rewrite/, $bs-value_as_list_recursive))
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
}
}
@@ -2092,7 +2097,7 @@
$lt ||= '';
$var-requires_variables ([EMAIL PROTECTED]@ used, $lt . 'ALLOCA');
$dep_files{'$(DEPDIR)/alloca.P' . $myobjext} = 1;
- require_file_with_macro ($cond, $var, FOREIGN, 'alloca.c');
+ require_libobj_with_macro ($cond, $var, FOREIGN, 'alloca.c');
saw_extension ('c
Re: [PATCH] Support AC_CONFIG_LIBOBJ_DIR
Hallo again,
It turns out that the automake patch is not enough :-(
Attached is an improved patch against automake-1.9.5 (applies to branch-1-9
and HEAD with fuzz). When applied, if configure.ac declares
AC_CONFIG_LIBOBJ_DIR, then automake will look in that directory for
AC_LIBSOURCE declared files. This allows us to have a single toplevel
Makefile.am, that builds a library in a subdirectory that contains
AC_LIBSOURCE source files. Without the patch, automake ignores the
AC_CONFIG_LIBOBJ_DIR, and complains that AC_LIBSOURCEs cannot be found in the
top level project directory.
2005-04-18 Gary V. Vaughan [EMAIL PROTECTED]
* automake.in (config_libobj_dir): Either `.' or whatever directory is
given to AC_CONFIG_LIBOBJ_DIR in configure.ac.
(scan_autoconf_traces): Set config_libobj_dir.
(require_libobj_with_macro): Use $config_libobj_dir when looking for
LIBOBJs.
(handle_LIBOBJS, handle_ALLOCA): Use it.
Also attached is a complementary patch against autoconf-2.59 (porting to HEAD
is trivial) which changes _AC_LIBOBJS_NORMALIZE to prepend the
AC_CONFIG_LIBOBJ_DIR subdirectory to each object named in LIBOBJS and
LTLIBOBJS, so that the substitutions into a toplevel Makefile set up as
described above will build and link the libobjs correctly.
2004-04-18 Gary V. Vaughan [EMAIL PROTECTED]
* lib/autoconf/general.m4 (_AC_LIBOBJS_NORMALIZE): Prepend each object
named in LIBOBJS and LTLIBOBJS with the subdirectory declared by
AC_CONFIG_LIBOBJ_DIR if any.
I can apply the autoconf patch if approved, but I have no write access to
automake CVS...
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
--- automake.in.orig 2005-02-12 10:06:56.0 +
+++ automake.in 2005-04-18 17:47:45.0 +0100
@@ -333,6 +333,10 @@
# in Makefiles.
my $am_config_aux_dir = '';
+# Directory to search for AC_LIBSOURCE file, as set by AC_CONFIG_LIBOBJ_DIR
+# in configure.ac.
+my $config_libobj_dir = '';
+
# Whether AM_GNU_GETTEXT has been seen in configure.ac.
my $seen_gettext = 0;
# Whether AM_GNU_GETTEXT([external]) is used.
@@ -2067,7 +2071,7 @@
if ($iter =~ /\.h$/)
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
elsif ($iter ne 'alloca.c')
{
@@ -2079,7 +2083,7 @@
my $bs = var ('BUILT_SOURCES');
if (! $bs || ! grep (/$rewrite/, $bs-value_as_list_recursive))
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
}
}
@@ -2092,7 +2096,7 @@
$lt ||= '';
$var-requires_variables ([EMAIL PROTECTED]@ used, $lt . 'ALLOCA');
$dep_files{'$(DEPDIR)/alloca.P' . $myobjext} = 1;
- require_file_with_macro ($cond, $var, FOREIGN, 'alloca.c');
+ require_libobj_with_macro ($cond, $var, FOREIGN, 'alloca.c');
saw_extension ('c');
}
@@ -4636,6 +4640,7 @@
AC_CONFIG_AUX_DIR = 1,
AC_CONFIG_FILES = 1,
AC_CONFIG_HEADERS = 1,
+ AC_CONFIG_LIBOBJ_DIR = 1,
AC_CONFIG_LINKS = 1,
AC_INIT = 0,
AC_LIBSOURCE = 1,
@@ -4731,6 +4736,11 @@
push @config_headers, $spec;
}
}
+ elsif ($macro eq 'AC_CONFIG_LIBOBJ_DIR')
+ {
+ $config_libobj_dir = $args[1];
+ check_directory ($config_libobj_dir, $where);
+ }
elsif ($macro eq 'AC_CONFIG_LINKS')
{
foreach my $spec (split (' ', $args[1]))
@@ -6975,6 +6985,22 @@
require_file ($macro-rdef ($cond)-location, $mystrict, @files);
}
+# require_libobj_with_macro ($COND, $MACRO, $MYSTRICT, @FILES)
+# -
+sub require_libobj_with_macro ($$$@)
+{
+my ($cond, $macro, $mystrict, @files) = @_;
+$macro = rvar ($macro) unless ref $macro;
+if ($config_libobj_dir eq '')
+ {
+ require_file ($macro-rdef ($cond)-location, $mystrict, @files);
+ }
+else
+ {
+ require_file_internal ($macro-rdef ($cond)-location, $mystrict,
+ $config_libobj_dir, @files);
+ }
+}
# require_conf_file ($WHERE, $MYSTRICT, @FILES)
# --
--- lib/autoconf/general.m4.orig 2003-10-27 11:10:56.0 +
+++ lib/autoconf/general.m4 2005-04-18 18:00:20.0 +0100
@@ -1,6 +1,6 @@
# This file is part of Autoconf. -*- Autoconf -*-
# Parameterized macros.
-# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
+# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2005,
# 2002, 2003, Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
@@ -2436,14 +2436,19 @@
# _AC_LIBOBJS_NORMALIZE
# -
# Clean up LIBOBJS abd LTLIBOBJS so
Re: [PATCH] Support AC_CONFIG_LIBOBJ_DIR
Hi Paul,
Paul Eggert wrote:
I like the patch from the Autoconf point of view, assuming the Automake
folks take their bit.
Thanks.
One small point:
Gary V. Vaughan [EMAIL PROTECTED] writes:
+ac_libobj_dir=
+test X${ac_config_libobj_dir-.} != X.
+ ac_libobj_dir=`echo $ac_config_libobj_dir/ | sed 's,/*$,/,'`
That would mishandle the case where ac_config_libobj_dir consists
entirely of slashes, or if it contains weird characters like
backslashes or newlines in unusual positions. Is this possible? If
so, how about something like this to avoid the problem?
ac_libobj_dir=
test X${ac_config_libobj_dir-.} != X.
ac_libobj_dir=`expr X$ac_config_libobj_dir/ : 'X\(.*[^/]\)' '|' 'X/' :
'X\(/\)'`
I think that does something different. The idea of my sed expression is
just to avoid adding a trailing slash if configure.ac contains, say,
AC_CONFIG_LIBOBJ_DIR([lib/]).
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
Re: Mixing BUILT_SOURCES, double quote include and separation of source and binary directory
Simon Perreault wrote: Hi, I have a problem which I figure must be fairly common, although I found no reference to it anywhere. I think it must be common because the SCons manual says they fixed it. [1] Anyway... Let's say I have two directories, src and include. I place main.c in src and inc.h in include. main.c includes inc.h this way: #include ../include/inc.h and inc.h includes built.h this way: #include built.h Now, my src/Makefile.am contains something like this: BUILT_SOURCES = ../include/built.h ../include/built.h: mkdir -p $(@D) touch $@ Everything works fine as long as I am building in the source directory. If I make a build directory and invoke configure and make from that directory, inc.h can't find built.h. And that's normal, since built.h is in build/include instead of include. Because it is not in the same directory as inc.h, including it using double quotes can't work. The quick fix is to add the location of inc.h, prefixed with $(top_builddir). However, in my real project I have hundreds of such files with hundreds of such locations. I would quickly hit the limit on command-line arguments. How should I fix this problem? In src/Makefile.am: AM_CPPFLAGS = -I$(srcdir)/../include -I../include Or if include and src are immediate children of the directory containing configure.ac: AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_builddir)/include HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: Still no joy....
Hallo Bruce! Bruce Korb wrote: I have now changed the Makefile.am thus: autogen_LDADD = $(top_builddir)/autoopts/libopts.la $(LIBGUILE_LIBS) Looks right to me. and autogen_LDFLAGS = -export-dynamic You only need -export-dynamic if you are going to use lt_dlopen (NULL) to get a reflective module handle... and even then, I think you only need it if the dlsym code is run from a dso rather than the sources for the autogen binary proper. The net result: + /home/bkorb/ag/ag/agen5/autogen \ -L/home/bkorb/ag/ag/autoopts argument.def /home/bkorb/ag/ag/agen5/.libs/lt-autogen: symbol lookup error: \ /home/bkorb/ag/ag/agen5/.libs/lt-autogen: undefined symbol: optionStackArg Is this an error from the runtime linker? Or from a dlsym/lt_dlsym call? What does ldd .libs/lt-autogen give you? What about ../libtool -mode=execute ldd ./autogen? + failure AutoGen could not process $ nm /home/bkorb/ag/ag/autoopts/.libs/libopts.so|fgrep optionStackArg bb31 T optionStackArg Presumably nm /usr/local/lib/libopts.so | grep optionStackArg give U? It is not finding the symbol because it is not looking in the current build directory. So, I guess I have a bug. Attached is the script /home/bkorb/ag/ag/agen5/autogen. I think what is needed should be clear from the above, but I'll be happy to send any more information that might be helpful! Argh, the attached wrapper appears to be clearing LD_LIBRARY_PATH. Are you using fast-install mode (./configure --enable-fast-install)? Does the autogen binary install without needing to be relinked? What architecture are you running all of this on at the moment? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: libtool non standard library name
Salut Jean-Denis, Jean-Denis Giguere wrote: I try to use libtool and automake to build 2 librairies named _gvmodule.la _gtkmissing.la . I use the following line in my Makefile.am : openevexec_LTLIBRARIES= _gvmodule.la _gtkmissing.la When I run automake I have the following error message : pymod/Makefile.am:4: `_gtkmissing.la' is not a standard libtool library name pymod/Makefile.am:4: did you mean `lib_gtkmissing.la'? pymod/Makefile.am:4: `_gvmodule.la' is not a standard libtool library name pymod/Makefile.am:4: did you mean `lib_gvmodule.la'? You should also add: _gvmodule_la_LDFLAGS = -module _gtkmissing_la_LDFLAGS = -module Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: Now for the note to the FSF that explains why we need it... here is a first cut to get the ball rolling: That looks fine to me. Thanks. Okay, there have been no corrections or objections in the last 24 hours... Where do we send it? Direct to rms? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Now for the note to the FSF that explains why we need it... here is a first cut to get the ball rolling: Autoconf, Automake and Libtool have long distributed m4 macro files that are needed to generate the familiar configure script. In the spirit of giving our users all the same rights that we developers have, our intention has always been to allow our users to distribute these m4 macros with their packages so that *their* users can regenerate the configure script if, say, they want to make a patch to get things to work on a platform that the package maintainer didn't have access to. For this purpose, all 3 autotools have historically had an exception to the GPL in those source files containing m4 macros used to generate a package configuration script, but unfortunately we have used different wordings and in a few cases forgotten to add the exception clause to a macro source file. We would jointly like to standardise on the wording of the exception clause, and add it into the few files that are currently missing it. As the copyright holder of these tools, our questions to you are: i) Is it okay for us to change the wording of the licenses in our m4 macro source files, and in some cases add in the missing exception clause, to clarify the spirit in which they have been distributed all along? ii) Is the following wording sufficiently clear from a legal point of view? Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, Paul if you distribute this file as part of a package that Paul automatically derives from this file a configuration Paul script (and perhaps some associated intermediate files), Paul then you may distribute this file and the derived files Paul for that purpose, under the same terms that you use for Paul the rest of the package. [...] President Eggert, you have my vote! Seconded :-) Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul Would you use the exact same wording in #2 that you Paul already uses in the aux scripts? Does that wording still Paul apply? I think so. Another idea would be to use a bison-like exception just to match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) Maybe: As a special exception to the GNU General Public License, when this file is used as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may use the resulting output file without restriction. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
On second thoughts, why not take this opportunity to unify the license exception between libtool and automake so we can share code more easily? Gary V. Vaughan wrote: Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul Would you use the exact same wording in #2 that you Paul already uses in the aux scripts? Does that wording still Paul apply? I think so. Another idea would be to use a bison-like exception just to match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) Maybe: As a special exception to the GNU General Public License, when this file is used as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may use the resulting output file without restriction. Instead: As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses it as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may include it under the same distribution terms that you use for the rest of that package. However, even though our intentions are good, and we are merely clarifying the existing spirit of the exception clauses we have used all along, is it okay to just edit the license of existing files without explicit permission from the authors? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: However, even though our intentions are good, and we are merely clarifying the existing spirit of the exception clauses we have used all along, is it okay to just edit the license of existing files without explicit permission from the authors? It's a tricky enough situation that we should probably take it up with the FSF itself. It owns the copyright. Agreed. Why don't we work up a clause that we all like, and draft a note explaining why we need the exception, and then we can forward it to the FSF for consideration... Was anybody unhappy with the exception wording in my last post in the thread? If not we can start from there. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: Was anybody unhappy with the exception wording in my last post in the thread? If not we can start from there. I worry that it's too generous, because it means that if the package uses the .m4 file as input to autoconf, then the package can also use the .m4 file for other, proprietary reasons. Good point. How about this wording instead? As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file as input to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute the resulting output files under the same terms that you use for the rest of the package. That limits non-GPL licensed packages to an aclocal.m4 based distribution method, rather than shipping the files and m4_including them with automake-1.8 and higher :-( Also, I'm not sure whether `input to GNU Automake' is good legalese for `feed it to aclocal'? Here's another: As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file as input to programs that are shipped as part of GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute this file for that purpose under the same terms that you use for the rest of the package. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, if you Paul distribute this file as part of a package that uses the file as input Paul to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute Paul the resulting output files under the same terms that you use for the Paul rest of the package. I don't understand the intent of as input to GNU Autoconf, GNU Automake, or GNU Libtool. AFAICT Libtool does not input m4 files, only the Autoconf tools and aclocal do. Just trying to cover all bases to avoid more pain for future autotools versions. Note that libtoolize does actually read through aclocal.m4 and any files it m4_includes to find a few directory paths and decide whether to copy particular files. We might extend that functionality in future. The use of GNU Autoconf is to prevent someone creating their own tool and calling that Autoconf to circumvent the license. [[...]] As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file (or any derived output) as input to generate its configuration script with Autoconf, then you may distribute the file and resulting output files under the same terms that you use for the rest of the package. configuration script generated by Autoconf is what the aux scripts already use. or any derived output is a lame attempt to allow tools such as aclocal (without singling out aclocal) to preprocess the file, as long as the intent is to build a configure script. I prefer my wording :-) Bruce's would be kinda cool too. But frankly, I'd be flabbergasted is the FSF bought that :-( Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Hi Ralf, Ralf Wildenhues wrote: Hi Peter, * Peter Ekberg wrote on Tue, Nov 09, 2004 at 01:33:29PM CET: Hello! There is no exception from the GPL in m4/ltoptions.m4, like there is in the other lt*.m4 files in that directory. Is that an oversight or is this file only needed for backwards compatibility or something like that? I based this file on m4/options.m4 in automake and copied the license from there :-( The lack of exception is troubling, maybe the author of the Automake version of the file is willing to let us relicense our fork? If not, we need to reimplement the parts I cribbed from Automake, so that we can license it consistently. Not only this file: also missing the exception are m4/argz.m4 m4/ltversion.m4 (is this short enough so it doesn't need any license?) m4/ltversion.in, and I believe the license is necessary. libltdl/Makefile.am libltdl/configure.ac libltdl/loaders/Makefile.am I wrote all of those, so the missing exception is just an oversight on my part. Please feel free to insert the missing clause. Otherwise I will do so when I have some time. Arguably libltdl/Makefile.am has ancestry from before I joined libtool, but the clause was already present in the libtool license when libltdl was added, so there is no problem in adding the clause back in. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: Wish: add a target install-list target in generated Makefile
bear wrote: The usual way to install a gnu software is ./configure make make install but can you add a install-list target which I can run make install-list to see what and where to install? Maybe there already is a solution. If so, can you tell me how to? If you are running a reasonable implementation of make (eg GNU Make): make -n install will show the commands that would be executed without actually running them. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: Configure options
Thomas Degris wrote: I guess this is not an automake question but I would like to know how I can disable static build by default (I mean activate the --disable-static by default) when running configure. http://www.gnu.org/software/libtool/manual.html#IDX79 -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: compile problem
Hallo! Ralf Wildenhues wrote: Alexandre Duret-Lutz writes: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: because AM_PROG_CC_C_O horribly overwrites CC, it's not clear to me whether AM_PROG_CC_C_O LT_INIT is equivalent to LT_INIT AM_PROG_CC_C_O It looks like Libtool's `-c -o' check would not give the same answer. I haven't dug all this; I think Ralf W sent some mail about it, but I haven't flushed all my mails yet. Agreed. From earlier conversation if would seem preferable to have AM_PROG_CC_C_O called first. Can't that be solved with a call to AC_BEFORE in AM_PROG_CC_C_O? Note that my conclusions were partly wrong because of several reasons: - I tried with the wrong order of AC_PROG_CC and AM_PROG_CC_C_O (this is fortunately solved now) - My first tests were done overwriting config.cache variables in a non-safe manner: Whether Libtool's _C_O test succeeds or fails depends partly on whether AM_PROG_CC_C_O was run before (and with what output). More complicating: Right now the tests do not use the same method to check, which means (and yes, this actually happens!) that either one can fail or succeed, and you have to actually look at all the possibilities. I especially don't like the Libtool check because it greps for compiler warnings instead of checking for the right output file. Warnings could have very different cause. Agreed again. _LT_COMPILER_C_O should probably be rewritten, and modelled after AC_PROG_CC_C_O. That done, we could also optimize it to look at the cache vars rather than rerunning the tests for compilers that have already been checked. But another issue I did find out: While Automake makes sure that all automake'n Makefiles use `compile' in the case of a bad compiler, Libtool has no way of making sure all compilations of `foo.c' are employed using `libtool'. This makes it impossible for libtool to guard against # This is part of a non-Automake Makefile libfoo.la: foo.lo bar: foo.o I don't follow... if Automake isn't involved, the user has to write their own inference rule for .lo don't they? I agree it would be better to set down a common lock scheme, although that really should not hold any release. In this case you *must* make sure that whenever Automake detects a bad compiler `C', Libtool detects `compile C' as a good compiler, in order to prevent deadlock. Sharing cachevars should take care of that. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: Feature request
Hi Albert, Albert Chin wrote: On Fri, Sep 17, 2004 at 10:50:09AM +0200, Andreas Schwab wrote: Albert Chin [EMAIL PROTECTED] writes: When building software with installable .m4 files (libtool, pkgconfig, gtk+, etc.), if each software program is installed to a separate directory, aclocal must be used like so: $ aclocal -I [path to libtool .m4 files] \ -I [path to pkgconfig .m4 files] ... How about an environment variable that aclocal would query that does the job of -I? pkgconfig uses the PKG_CONFIG_PATH variable giving locations for pkg-config to query for .pc files. Doing something similar with aclocal would make automating use of aclocal in build scripts much easier. Put the options in ACLOCAL_AMFLAGS in the toplevel Makefile.am and autoreconf will take care of everything. Thanks. However, I prefer a solution where I didn't have to modify the source if I modified the scripts used to build the software. It may be small consolation, but the next release of GNU m4 has the last bit of functionality required to eliminate aclocal entirely. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: Feature request
Albert Chin wrote: On Fri, Sep 17, 2004 at 02:49:05PM +0100, Gary V. Vaughan wrote: It may be small consolation, but the next release of GNU m4 has the last bit of functionality required to eliminate aclocal entirely. How does it do that? If the .m4 files for libtool 1.4 are in /opt/libtool14 and the .m4 files for libtool 1.5 are in /opt/libtool15, I'd still like an environment variable that defines the .m4 search path. Or, does this then become an autoconf problem and not an automake one because of the new GNU m4 feature? The latter. I suspect that unless you write a patch yourself, the automake guys are unlikely to work on a feature for aclocal when it is destined for /dev/null. I called it a small consolation because the autoconf guys are not yet quite ready to subsume aclocal's funtionality into autoconf itself, so they probably aren't in a position to accept patches either :-( I do agree that when autoconf is setting the M4PATH, it should take notice of an AC_MACRO_PATH environment setting or similar. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: tests in subdirectories
Hi Bob! Bob Friesenhahn wrote: Is no one else in the world interested in invoking tests in subdirectories? I'm interested :-) I tried to convert libtool a year or two ago and tripped over exactly the same problems, so I don't know how to make it work either! I guess autotest should support this by default (if it doesn't already)... Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: compile problem
Alexandre Duret-Lutz wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary So does that simply mean that libtool objects can be correctly built Gary as subdir-objects without AM_PROG_CC_C_O? Sorry to bug you, just Gary making sure I understand why you made the patch the way you did... The purpose of AM_PROG_CC_C_O is to replace CC by the `compile' script which emulates a compiler that supports `-c -o' when the real CC does not. As you pointed out, libtool already supplies such emulation, so `compile' is never needed when compiling lo files. Okay. But for a project built with `make -j', we still need AM_PROG_CC_C_O and _LT_COMPILER_C_O to understand each others' locks :-( [...] Gary Meant to ask, why doesn't AM_INIT_AUTOMAKE (conditionally if Gary necessary) simply invoke AM_PROG_CC_C_O? We know it's needed only after processing the Makefile.am files. Why not invoke it anyway? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: compile problem
Bob Friesenhahn wrote: On Fri, 10 Sep 2004, Gary V. Vaughan wrote: Okay. But for a project built with `make -j', we still need AM_PROG_CC_C_O and _LT_COMPILER_C_O to understand each others' locks :-( [...] Gary Meant to ask, why doesn't AM_INIT_AUTOMAKE (conditionally if Gary necessary) simply invoke AM_PROG_CC_C_O? We know it's needed only after processing the Makefile.am files. Why not invoke it anyway? If the compile script is unnecessarily used, then compilation will be even slower. This seems particularly true for the Windows operating system where compilation using libtool already feels like compiling in molasses. It seems that Windows is very slow at executing (fork/exec) new programs. I'm not saying that the compile script should be used, just that the tests to determine whether it might be needed are run as a matter of course. Looking at the implementation of AM_PROG_CC_C_O, I see that it would need a bit of refactoring to make that happen... My feeling at the moment is that it would be a small price to pay for simplifying the interface to automake (i.e. _not_ being sometimes told, partway through the automake run, that you must change your configure.ac and start again at the aclocal stage). I'd be happy to implement it as part of an overall patch to unify ..._C_O locking emulation between automake and libtool. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: compile problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Salut! On 7 Sep 2004, at 22:03, Alexandre Duret-Lutz wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary Do we need to patch automake to accept LT_INIT for Gary subdir-objects projects, or do you think AC_PROG_CC_C_O Gary should be merged with _LT_COMPILER_C_O? It's AM_PROG_CC_C_O Automake needs, not AC_PROG_CC_C_O. Meant to ask, why doesn't AM_INIT_AUTOMAKE (conditionally if necessary) simply invoke AM_PROG_CC_C_O? Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBPjxmFRMICSmD1gYRAgeaAJ4/wq5y1z5VnCj7b2Qdbvpc/7IewgCfeK0l bWg3f/gPk4Ods4JOJrFtTNU= =F7Z1 -END PGP SIGNATURE-
Re: compile problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Salut Alexandre! Welcome back. Hope you enjoyed your vacation :-) On 7 Sep 2004, at 22:03, Alexandre Duret-Lutz wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] On Mon, Aug 23, 2004 at 08:29:07PM +0100, Patrick Welche wrote: I just tried to build cvs libtool with cvs auto* all from today, and get: make all-recursive Making all in . cd . /bin/ksh /usr/src/local/libtool/config/missing --run automake-1.9a --gnits libltdl/Makefile.am: C objects with per-target flags but `AM_PROG_CC_C_O' not in `configure.ac' [...] Gary Libtool has a non compiler specific version of that macro called Gary _LT_COMPILER_C_O which is automatically called by LT_INIT. Gary Do we need to patch automake to accept LT_INIT for Gary subdir-objects projects, or do you think AC_PROG_CC_C_O Gary should be merged with _LT_COMPILER_C_O? It's AM_PROG_CC_C_O Automake needs, not AC_PROG_CC_C_O. I'm installing the following. 2004-09-07 Alexandre Duret-Lutz [EMAIL PROTECTED] * automake.in (lang_c_rewrite): Do not require AM_PROG_CC_C_O for libtool objects. (handle_single_transform): Pass nonansi_obj to $subr so lang_c_rewrite can distinguish libtool objects. * tests/libtool7.test: Use subdir-objects without using AM_PROG_CC_C_O. Report from Gary V. Vaughan and Patrick Welche. Once again, my perl-fu is insufficuent to the task :-@ So does that simply mean that libtool objects can be correctly built as subdir-objects without AM_PROG_CC_C_O? Sorry to bug you, just making sure I understand why you made the patch the way you did... Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBPjW5FRMICSmD1gYRAncvAJ9Vk5L6BRYLA19gmwIQPjl/BIVkRACgsrDt 0LC36TBijrewpEn+Bg1kaBo= =mu7v -END PGP SIGNATURE-
Re: non-recursive make and tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Bob,
On 31 Aug 2004, at 06:08, Bob Friesenhahn wrote:
On Mon, 30 Aug 2004, Bob Friesenhahn wrote:
The $(srcdir) value passed is often essentially useless since it may
just be '.'. It is difficult for the Makefile to produce better
values except for perhaps offsets from @abs_top_srcdir@ and
@abs_top_builddir@ substitutions. It may also be possible to play
games by passing back-ticked shell script fragments rather than
normal values in the TESTS_ENVIRONMENT specification.
Regardless, the tests themselves should not have to know their
position in the source or build tree.
If I add this sort of junk to the top of my test scripts then they
seem to pass the tests:
set -e
SRCDIR=`dirname $0`
SRCDIR=`cd $SRCDIR pwd`
TOPSRCDIR=`cd $srcdir pwd`
cd utilities || exit 1
MODEL_MIFF=${TOPSRCDIR}/Magick++/demo/model.miff
.
.
.
Without the pwd's distcheck can't pass since srcdir may be passed as a
useless '.'.
Unfortunately, with hundreds of such scripts, altering the test
environment to convert to a non-recursive make is quite a penalty.
Many scripts could be one-liners if Automake can produce a
per-directory test environment.
I made a stab at converting libtool to non-recursive make last year (I
think) and had much the same problem. I think the general solution is
to move to an Autotest based testsuite, where the input files are
generated by the test rather than searched for in the source tree.
Maybe you can emulate that behaviour by making your test input into
here documents in the test scripts, without a whole scale move to
Autotest?
Cheers,
Gary.
- --
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (Darwin)
iD8DBQFBNFsBFRMICSmD1gYRAvmXAJ9b+/z3QyLJlvF/yqV6j67yHoiZEwCgjO3/
/4KCRgLIGY6u8TYeyDL5nY4=
=cRSu
-END PGP SIGNATURE-
Re: non-recursive make and tests
Hi Bob! Bob Friesenhahn wrote: On Tue, 31 Aug 2004, Gary V.Vaughan wrote: That sounds great, but in my case the input files are graphic image files so they would be rather unwieldy in here documents. Typically a file is read, processed using an algorithm, and then either its checksum is compared with a reference checksum, or the final output is compared with reference data. There are lots of other types of software packages with tests that have similar requirements. The easiest solution is to update the check-TESTS: definition in automake's lib/am/check.am file so that it has an option to emulate the way a test would traditionally be executed by a recursive build. I can hack my copy of Automake, but then the resulting project can't be re-created by someone else. Agreed. I think your best course of action is to put a patch in the automake queue for Alexandre's return from vacation :-( Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: executing shell commands (like cp)
noinst_DATA = libname.so libname.so: libname.la @rm -f $@ $(LN_S) .libs/$@ $@ Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: compile problem
Hi Alexandre! Your automake patch of 2004-08-04 causes this to happen: Noah Misch wrote: On Wed, Aug 25, 2004 at 07:51:01PM +0100, Patrick Welche wrote: On Mon, Aug 23, 2004 at 08:29:07PM +0100, Patrick Welche wrote: I just tried to build cvs libtool with cvs auto* all from today, and get: make all-recursive Making all in . cd . /bin/ksh /usr/src/local/libtool/config/missing --run automake-1.9a --gnits libltdl/Makefile.am: C objects with per-target flags but `AM_PROG_CC_C_O' not in `configure.ac' Am I alone? It seems I am.. I definitely need to do as the error message says (add AM_PROG_CC_C_O to configure.ac) in order to be able to compile libtool.. I saw the same thing when I bootstrapped a fresh checkout of libtool on 2004-08-24 using builds of equally recent checkouts of autoconf and automake. I have not yet had the opportunity to isolate the cause. Libtool has a non compiler specific version of that macro called _LT_COMPILER_C_O which is automatically called by LT_INIT. Do we need to patch automake to accept LT_INIT for subdir-objects projects, or do you think AC_PROG_CC_C_O should be merged with _LT_COMPILER_C_O? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: uninstall fails to remove library
Hi Stephen, Stephen Torri wrote: When make installs a library via make install it gets place in the correct location as a .so file. Yet when make uninstall is run it fails to remove the .so file. The reason for the failure is that its looking for the .la file and not the .so. libtool: 1.4.3-r4 /bin/sh ../../../libtool-nofpic --mode=install /bin/install -c xineplug_post_planar.la /bin/sh ../../../libtool-nofpic --mode=uninstall rm -f What is libtool-nofpic? Is that a gentoo patched libtool? The 1.4 series of libtool comes from a branch made in early 2001, and had an uninstall bug similar to what you describe. Please upgrade to a recent 1.5.x release and try again. If you still experience problems, please report them to [EMAIL PROTECTED] Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
ltmain.sh
Hi Alexandre!
Having automake choke when ltmain.sh is missing causes no end
of trouble for libtool... because obviously we don't have ltmain.sh
yet at bootstrap time. We work around it by having a bootstrap
script touch ltmain.sh before running automake, and then removing
it so that make triggers the right rules to rebuild it properly.
None of the automatic rebuild rules work:
] make
cd .. /bin/sh /Users/gary/devel/savannah/libtool--devo--1.0/config/missing
--run automake-1.8c --gnits Makefile
configure.ac:179: required file `config/ltmain.sh' not found
make: *** [../Makefile.in] Error 1
And worst of none of the dist rules work properly. In a VPATH build
tree, we make ./config/ltmain.sh, but automake expects to see it in
$(srcdir)/config/ltmain.sh and chokes:
] make dist
{ test ! -d libtool-1.5a || { find libtool-1.5a -type d ! -perm -200 -exec
chmod u+w {} ';' rm -fr libtool-1.5a; }; }
mkdir libtool-1.5a
mkdir -p -- . libtool-1.5a/. libtool-1.5a/config libtool-1.5a/m4
...
make[2]: *** No rule to make target
`/Users/gary/devel/savannah/libtool--devo--1.0/tests/cdemo/../../config/ltmain.sh',
needed by `distdir'. Stop.
make[1]: *** [distdir] Error 1
make: *** [distdir] Error 1
If I copy everything into a new tree and configure in top_srcdir, make
dist will work, but distcheck fails the VPATH tests :-(
I've added the following rules to the top-level Makefile.am, and they
do mitigate things a lot:
$(top_srcdir)/config/ltmain.sh: config/ltmain.sh
$(LN_S) config/ltmain.sh $(top_srcdir)/config/ltmain.sh
dist-hook:
test -f $(top_distdir)/config/ltmain.sh || \
$(LN_S) config/ltmain.sh $(top_distdir)/config/ltmain.sh
I think that what we *really* need is for automake to not assume ltmain.sh
is in the source tree, and some way for the libtool Makefile.am to
declare that config/ltmain.sh is a built file so that automake doesn't
keep stopping before it is built without the horrible bootstrap $fakes
hack.
Unfortunately, at the moment we need to rebootstrap the whole tree far
more often than necessary where other projects just rerun automake as
part of the make invocation. Rerunning autoreconf -fvi on all 8 test/*demo*
trees and the libtool source tree proper after every cvs update and commit
takes about 30 minutes on my high end Mac, and up to an hour for some of
our other developers :-(
Thoughts?
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
Re: searching for libtool.m4 in tests/defs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | The Automake test suite (CVS HEAD version) explicitly looks for | libtool.m4 in aclocaldir and a list of directories specified in the | dirlist file there. Now recent CVS Libtool versions remove libtool.m4 | from that location and add it to .../share/libtool/m4/ . | This lead to many SKIPped tests in the test suite (quite silently, by | the way). How would I resolve this issue correctly? Is this an | Automake, a Libtool or a user problem? Why is there no standard way to | ask a libtoolize for its corresponding m4 files (at least, one would | think, newer versions would improve this situation)? That is a good idea. What do you think the interface should be? Maybe: $ libtoolize --macro-files /usr/local/share/libtool/m4/libtool.m4 /usr/local/share/libtool/m4/ltdl.m4 /usr/local/share/libtool/m4/ltoptions.m4 /usr/local/share/libtool/m4/ltsugar.m4 /usr/local/share/libtool/m4/ltversion.m4 Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAtg/6FRMICSmD1gYRApD8AJ4sSirtBJNYdYF+51eUFVHydGNsBgCfQ4wx TtafwumTe1g6bGzx7iY0jKk= =jHT5 -END PGP SIGNATURE-
Re: [ot]wiki for auto* tools?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay West wrote: | As to where it could be homed... | | I own an ISP/webhosting/colocation firm and could house the wiki on one of | my servers in a world class datacenter with multiple 100mb upstream | connections. I could even dedicate a server just to that. But then, I | haven't gotten a single answer from the list to my pleas for help on one | single question on what I'm guessing is a simple problem with libtool. | | I'll host it in exchange for someone taking 60 seconds to answer my previous | post ;) I already answered last week: http://mail.gnu.org/archive/html/automake/2004-05/msg00053.html Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFArg+0FRMICSmD1gYRAhE6AJwP5nIchZCUhyUf6eA/OL5+7wa5KACfWglb bsowObk6RD9Vqlo0KUbqHBQ= =fYoo -END PGP SIGNATURE-
Re: Problems after upgrading gnu tools
Jay West wrote: 2) I was always getting this other problem, even before upgrading. It's a minor annoyance but was wondering if someone could tell me what was happening or if it was a bug. Several times during a configure, configure is looking for the maximum length of command line arguments. On all the times it tests except one, it gets a numeric sensible result... but every time on ONE of the tests, I get the following: checking whether f77 accepts -g... yes checking the maximum length of command line arguments... expr: syntax error checking command to parse /usr/bin/nm -B output from gcc object... ok Any thoughts on why this happens just once, and the other times this test is performed (during the same configure session) it works? It was a bug, fixed in autoconf CVS by the patch in: http://mail.gnu.org/archive/html/autoconf-patches/2004-04/msg00028.html Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: Libtool's manual disparages Automake! :-o
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Duret-Lutz wrote: |Gary == Gary V Vaughan [EMAIL PROTECTED] writes: | | | [...] | | Gary should Automake be patched to accept `program_LDADD = | Gary -dlopen foo.la'? | | Sorry for the delay. No worries. It gave me time to audit the m4 sources for savannah-compromise :-) | This should work since Automake 1.4b. | It's documented and regression-tested. So it does! I'm changing the demo dirs and manual to use program_LDADD :-D Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFARF8VFRMICSmD1gYRAq6mAKCP91LOVjF9RM7Zuj2NRPDtl9ScGQCeMg4z 8s4+01VhrOf7/2uld6PRjTU= =BnUm -END PGP SIGNATURE-
Re: Automatic regeneration of libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Salut Alexandre, Alexandre Duret-Lutz wrote: |Gary == Gary V Vaughan [EMAIL PROTECTED] writes: | Gary Instead, I'd like to have LT_INIT perform the | Gary AC_SUBST([LIBTOOL_DEPS]), and Automake generate the | Gary following rule when libtool is in use: | | Gary $(LIBTOOL): $(top_builddir)/config.status $(LIBTOOL_DEPS) | Gary cd $(top_builddir) $(SHELL) ./config.status $@ | | Gary Does that seem like a sensible thing to want? | | What does LIBTOOL_DEPS contains? For current libtool, LIBTOOL_DEPS always points at the ltmain.sh that was used to generate the libtool script. In the future, we might remove ltmain.sh in favour of an m4sh based libtool generation, in which case it would become empty. More on this in a moment... | It's unclear to me when | libtool needs to be rebuilt and how me managed without such rule | so far. I think libtool needs to be rebuilt whenever a project is re-libtoolized, which can be detected by having a newer ltmain.sh. This works best with links I expect, but if someone (say 'autoreconf -f' ;-) 'libtoolize --copy --force's their tree, it is not unreasonable for libtool itself to be rebuilt (and thence libtool objects recompiled). | Except in the Libtool package itself, I believe | libtool.m4 does change when ltmain.sh changes, doesn't it? Theoretically we could make a point release that changes the contents of one but not the other (relative to the previous release): and libtoolize no longer blindly overwrites either file if there are no changes in serial number (excepting --force of course). LIBTOOL_DEPS should probably include a list of the srcdir macro files too to catch this case. | So libtool would get updated as a side-effect of | rebuilding/rerunning configure. Yes, that is true. But does configure get rebuilt automatically if a tree is relibtoolized? I don't think the current automake rules notice that ltmain.sh has been touched. | I have a small problem with using $(LIBTOOL) as a target of a rule, | because many people have overwritten LIBTOOL in they Makefile.am | to insert a --tag option. Good point. Perhaps Automake could /s, -[-a-zA-Z0-9]*,,g/ on $(LIBTOOL) and put the result of that in place of the $(LIBTOOL) target in Makefile.in? Or maybe we need a LIBTOOL_FLAGS to hold the options? | Also such a rule would be triggered only if something depends on | $(LIBTOOL), which I believe is not the case (same problem with | --tag here). Is such a dependency desirable? IOW should every | libtool target be recompiled whenever config.status changes? Well, if libtool has been regenerated, and is different, then certainly libtool targets should be recompiled. If config.status has changed, then there is a real possibility that libtool will be different, and having libtool objects from different builds of the libtool script scattered around the tree is definitely to be avoided! :-/ I don't think we can get any finer granularity than this; and it is better to be conservative than force a frustrated user to 'make distclean' and start again when things go awry. FYI, there has been some version of the $(LIBTOOL) target rule in all of the Makefile.ams in the libtool dist for as long as I can remember (about 5 or 6 years on a lucid day ;-) ... Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFARGmSFRMICSmD1gYRAshWAJ9WADAUjQXEZQRu65CL1YDG3zt+1wCgzhWO jRLKoQ0l7DEIR5hzmeyw6Xg= =k+pp -END PGP SIGNATURE-
Automatic regeneration of libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The libtool manual currently states: ~ This macro also sets the shell variable LIBTOOL_DEPS, that you can ~ use to automatically update the libtool script if it becomes ~ out-of-date. In order to do that, add to your `configure.in': ~ LT_INIT ~ AC_SUBST(LIBTOOL_DEPS) ~ and, to `Makefile.in' or `Makefile.am': ~ LIBTOOL_DEPS = @LIBTOOL_DEPS@ ~ libtool: $(LIBTOOL_DEPS) ~ $(SHELL) ./config.status --recheck ~ If you are using GNU automake, you can omit the assignment, as ~ automake will take care of it. You'll obviously have to create ~ some dependency on `libtool'. Instead, I'd like to have LT_INIT perform the AC_SUBST([LIBTOOL_DEPS]), and Automake generate the following rule when libtool is in use: $(LIBTOOL): $(top_builddir)/config.status $(LIBTOOL_DEPS) cd $(top_builddir) $(SHELL) ./config.status $@ Does that seem like a sensible thing to want? Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAO5fJFRMICSmD1gYRAitFAJ4tGZdyPUdFfgS2CAtJ2vAayniwLwCeLTpi aKRe1g3IXj0+8CXms+xZPlY= =mJvA -END PGP SIGNATURE-
Re: --program-prefix leads to broken libtoolize
On Tuesday, February 3, 2004, at 09:14 pm, Scott James Remnant wrote: Of course, we could just steal the following off Automake ;-) :-D LOL Patch attached, okay to apply? +2004-02-03 Scott James Remnant [EMAIL PROTECTED] + + * Makefile.am (install-data-hook): Manually make config.guess + and config.sub executable after they are installed as _DATA. + We can't use _SCRIPTS because the various program name + transforms may be applied to them. + (dist_pkgdata_DATA): List config.guess and config.sub here + (pkgdata_SCRIPTS): instead of here. Okay. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: RFC: doc for `Handling Tools that Produce Many Outputs'
Hi Alexandre! On Saturday, January 31, 2004, at 10:28 pm, Alexandre Duret-Lutz wrote: That way, if `data.h' is required and `data.foo' is out of data, the dependency on `data.c' will trigger the build. That way, if `data.h' is required and `data.foo' is out of _date_, the Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: utility programs used during build
On Tuesday, January 13, 2004, at 06:05 pm, Warren Turkal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 13 January 2004 05:54 am, Gary V. Vaughan wrote: Warren Turkal wrote: | Is there any analysis on what it would take to create utility programs | that are only used during build in a crosscompiled environment in | automake? | | I and working on the libX11 for Freedesktop.org and it builds a file and | uses it during installation, but does not install it. I am under the | impression that automake does not support this right now. What would be | needed to add support for this feature. Does this work? nodist_PROGRAMS = installtool install: installtool I don't undersand what your example does. Isn't nodist implied on PROGRAMS? Yes it is, I meant noinst_, but my fingers typed nodist_ :-/ The following example is closest I can come up with. It will not work if you are cross compiling. noinst_PROGRAMS = installtool That's what I meant. installtool_SOURCES = installtool.c This is implied. If no sources are given, $PROGRAMNAME.c is used by default. It will attempt build a host targetted binary. That binary will not run on the build system. This is why I think automake needs to be extended. It depends on the compiler you use. If you have configured with a crosscompiler, it will do that yes. Maybe you can override it? You would have to copy the compile and link rules from the generated Makefile into your Makefile.am, and then change the compiler to $(CC_BUILD) or something... I didn't see your other message until after I answered this one. You are right that it would be nicer if Automake had built in support for such things. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: utility programs used during build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warren Turkal wrote: | Is there any analysis on what it would take to create utility programs that | are only used during build in a crosscompiled environment in automake? | | I and working on the libX11 for Freedesktop.org and it builds a file and | uses it during installation, but does not install it. I am under the | impression that automake does not support this right now. What would be | needed to add support for this feature. Does this work? nodist_PROGRAMS = installtool install: installtool - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAA9x2FRMICSmD1gYRAtCyAJ9iO0eW5/THZIhH7qPAsxbOuh9IeQCgiB6p EYf81/l4CKfrlrM+/tgJL0Y= =TxXU -END PGP SIGNATURE-
Re: config.guess and freedom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Corsepius wrote:
| I don't know how libtool applies config.guess and if/how my
| problems with libtool are connected to config.guess'ing.
Here is a short (but not atypical) example of the sort of thing libtool needs
config.guess for:
case $host_os in
aix3*)
~ # AIX sometimes has problems with the GCC collect2 program. For some
~ # reason, if we set the COLLECT_NAMES environment variable, the problems
~ # vanish in a puff of smoke.
~ if test X${COLLECT_NAMES+set} != Xset; then
~COLLECT_NAMES=
~export COLLECT_NAMES
~ fi
~ ;;
esac
We use it frequently:
$ fgrep 'case $host' `which libtool` \
- - /usr/local/share/libtool/m4/*.m4 | wc -l
~ 71
| Anyway, my comment was meant generally. I was referring to attempts to
| apply config.guess'ed valued to configuration tables, e.g. something
| similar to this:
| case $host_os in
| redhat7.3) f=/etc/txt.cfg;;
| redhat8.0) f=/etc/sysconfig/txt.cfg;;
| redhat*) f=/etc/foo/txt.cfg;;
| suse9.0) f=/etc/var/txt.cfg;;
| solaris*) f=/etc/config/txt.cfg;;
| ...
| esac
Not dissimilar, excepting your emphasis on linux distributions. I have no
strong opinion on the linux-gnu argument, but I think your original comment
devalues config.guess unfairly.
Cheers,
Gary.
- --
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://www.oranda.demon.co.uk
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQE//Xp2FRMICSmD1gYRArGqAKDDVyomDdqgjwtxQ1oFTO+ZTKXjmACfe+0j
Xc3D26rk22waSaTQqSYIN4g=
=Hh5H
-END PGP SIGNATURE-
Re: config.guess and freedom
On Thursday, January 8, 2004, at 04:32 pm, Ralf Corsepius wrote: Wrt. your example: You are supporting aix3*. Now IBM renames AIX to something else or changes some fundamental characteristics of their OS without changing the $host_os. All you can do is to extend, extend and extend your case. Agreed, but often that is easier than writing comprehensive checking code. How would libtool find out what the shared library soname versioning algorithm is with runtime tests for example? Another problematic case is ensuring correctness of guess-derived results. Without additional checks, you can't guarantee anything. Eg. wrt. host_os, you can't guess on the object format or if an OS honors LD_LIBRARY_PATH/LD_RUN_PATH or other advanced linker features libtool might require on a system (I am not a libtool expert, so bare with the examples). Libtool has however done exactly this with reasonable success for the last 8 years... There are cases where testing $host is simply the path of least resistance, but pragmatism is not a bad thing. To me, using config.guess'ed values should only be applied as absolute last resort if all else fail. In any case using them is fragile. I don't disagree with any of the points you make, but libtool probably wouldn't have ever got off the ground at all if all of the parameters it needs to check had to be probed from first principles. The beauty of open source is that if something is causing a real problem, it can be fixed and patched up stream. config.guess is without a doubt a very useful piece of code, and libtool is a prime example where leveraging it has probably saved thousands of programmers untold pain. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: bootstrapping CVS libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott James Remnant wrote: | On Wed, 2003-11-26 at 15:49, Gary V. Vaughan wrote: | | |Scott James Remnant wrote: ||On Wed, 2003-11-26 at 11:41, Gary V. Vaughan wrote: || 1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at install || time || 2: keep copies of the latest versions only in $prefix/share/libtool/m4 || 3: maybe we need a new $prefix/share/aclocal/ltcompat.m4 with stubs for || the macros you list above to keep aclocal happy? || || || We wouldn't need the stubs if aclocal could only see one libtool.m4. | |Agreed. And 1+2 achieves this. I'll post a patch shortly. | | | Did you ever get very far with this patch? It is next on my TODO list. I got a bit distracted with a rewrite of the libtool generation macros in libtool.m4. And Christmas :-o Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/+wXmFRMICSmD1gYRAhq/AJ9GucBOA2KKNkzfIOEqG2EJSkn1lwCgxBX0 n2i9zp+tA3hi/G1bi/+WH0s= =D+Tn -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: aclocal 1.8 no longer loads overridden macros
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Schwab wrote: | Here is a testcase: | | $ cat configure.ac | AC_INIT([aclocal-test], [0]) | AC_PROG_CC | AC_OUTPUT | $ cat prog-cc.m4 | undefine([AC_PROG_CC]) | AC_DEFUN([AC_PROG_CC], [echo [AC_PROG_CC] dummy]) | $ aclocal -I . | $ cat aclocal.m4 | cat: aclocal.m4: No such file or directory | | The problem is caused by the call to undefine, this loses the traced | attribute. You might try a CVS version of GNU m4... from the ChangeLog: 2001-10-10 Gary V. Vaughan [EMAIL PROTECTED] ~The trace semantics now attach the trace bit to a symbol name. ~For as long as a traceon(`foo') is active, calls to foo will be ~traced regardless of intervening undefines or module unloads. In anticipation of your next question: $ export CVS_RSH=ssh $ cvs -d :ext:[EMAIL PROTECTED]:/cvs-2003-09-16/m4 co m4 :-) Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/4H1zFRMICSmD1gYRAsfkAJ0TC2Z40q7drFalKMYv9W0vV3dBOACaAjxs VBlaamRDhskFw3O5dKQZZuU= =CPLg -END PGP SIGNATURE-
Re: Desired feature
On Wed, 3 Dec 2003 13:24:11 -0600 (CST), Bob Friesenhahn [EMAIL PROTECTED] said: It would be useful if Automake supported a set of options (e.g. LDFLAGS) which are applied only when building libraries or when building programs. It is excessively painful to have to add per-target _LDFLAGS options. Perhaps there should be both 'LT' and non-'LT' macro versions. Certainly this can be accomplished by overriding Automake's standard LINK and COMPILE definitions, but overriding standard definitions is risky. Seconded! It would be great to have `LT_LDFLAGS = -module', rather than 15 lines of `foo_LDFLAGS = -module' in a future m4 Makefile.am :-) Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: Desired feature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Duret-Lutz wrote: | On Thu, Dec 04, 2003 at 08:49:04AM +, Gary V. Vaughan wrote: | |It would be great to have `LT_LDFLAGS = -module', rather than 15 lines of |`foo_LDFLAGS = -module' in a future m4 Makefile.am :-) | | | Regarding M4: last time I checked you had a directory dedicated to | modules. Why don't you simply use AM_LDFLAGS = -module in this | directory? That's how I do it at the moment, but I want to convert to a non-recursive make, and then the AM_LDFLAGS will apply to the other directories as well. | More generally I think adding an LT_LDFLAGS variable is not a | solution, because some day Bob will come and say Now I need a global | LDFLAGS variable for standard libtool libraries, and another different | LDFLAGS for libtool modules; not being able to distinguish these two | sets of libraries is an extremely annoying (magnitude 42 on Richter's | scale) misfeature of Automake. :-D | Maybe we need a way to apply flags to groups of files, and tying flags | to dir_PRIMARY variables (as in bin_PROGRAMS_LDFLAGS) would be an | option. Agreed. That is definitely a better solution, I like it a lot :-) Actually, now that you point it out, I would hit that problem myself, since m4 has normal _LTLIBRARIES, noinst_LTLIBRARIES and modules. I would be happy if I could do this: ~AM_LDFLAGS = everything gets these ~noinst_LTLIBRARIES_LDFLAGS = these are for convenience libs ~lib_LTLIBRARIES_LDFLAGS = these are for other libtool libs ~libm4_la_LDFLAGS = but I can override non module libs individually That is, I think target specific flags should override PRIMARY group flags, not be in addition to them. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/zxnCFRMICSmD1gYRAvlQAKCehVcMvZ0W71Wk3FIFHTDgca7LvACgqnMV AimUpITNy5koaMWEPe+rZLc= =EmD/ -END PGP SIGNATURE-
Re: Desired feature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Friesenhahn wrote: | Automake should support | | o inheritance of standard configure flags LDFLAGS | o flags common across all targets AM_LDFLAGS | o additional flags common to a grouping of targets dir_PRIMARY_LDFLAGS | o additional flags specific to just one target target_LDFLAGS | o a way to override common flags at any level. overriding is the default for target_LDFLAGS vs dir_PRIMARY_LDFLAGS, which you can bypass with `target_LDFLAGS = $(dir_PRIMARY_LDFLAGS) -foo'. I can't think of a nice syntax where addition is the default, and overriding must be specified. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/z2DnFRMICSmD1gYRAnKgAKCtElBkOY1XV19C/SlO0T+DgFny2gCcCSEB km/SpMwrWm/xxMIThLziFcQ= =EUAg -END PGP SIGNATURE-
Re: 'ccache gcc' as compiler with libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Duret-Lutz wrote: | How can automake determine whether the version of libtool used in | a package supports --tag ? test -n `libtool --help | grep -- --tag=TAG` - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/xxkqFRMICSmD1gYRAvqDAJ0UYla3lIDVKlhhlhs5rmiRt/63WQCgvLkL yoMNFIPxxwHAE21o/XwyLaA= =MtPN -END PGP SIGNATURE-
Re: 'ccache gcc' as compiler with libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Duret-Lutz wrote: |Gary == Gary V Vaughan [EMAIL PROTECTED] writes: | | | Gary Alexandre Duret-Lutz wrote: | How can automake determine whether the version of libtool used in | a package supports --tag ? | | Gary test -n `libtool --help | grep -- --tag=TAG` | | But libtool doesn't exist at the time automake runs, does it? Good point. | An autoconf macro that we can trace would be ideal. _LT_AC_TAGCONFIG exists in branch-1-5 and HEAD. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/xx9sFRMICSmD1gYRAhPQAJ9vc+feQi+uJcuekIwNJIdg9aR6KwCgw6mP tTQD8yzAXxec3yo36GPqVlU= =LuO2 -END PGP SIGNATURE-
Re: bootstrapping CVS libtool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott James Remnant wrote:
| On Tue, 2003-11-25 at 13:27, Gary V. Vaughan wrote:
|
|
|Scott James Remnant wrote:
|| The gotcha is that for some reason aclocal pulls in both m4/libtool.m4
|| AND /usr/share/aclocal/libtool.m4 into aclocal.m4 and puts the latter
|| last, so its macros get used.
|
|This means that aclocal has found a dependency on a macro that is defined in
|/usr/share/aclocal/libtool.m4, but not $top_srcdir/m4/libtool.m4 (m4_defined
|macros can't be seen by aclocal.m4). If you have time to investigate, it
|would be nice to prevent this happening before we release.
|
|
| Ok, I've investigated this and I think the problem is that we're
| assigning too much intelligence to aclocal :-(
|
| As far as I can tell it has two basic phases:
|
| 1) Scan every m4 file and build up a list of AC_DEFUNs (or AU_DEFUN) it
|can find, and remember which file it found them in[0].
|
| 2) Scan configure.{ac,in} looking for the name of any macro it saw a
|definition for, pull in the appropriate file and then scan that file
|in the same way (recurse until happy).
|
| [0] Interestingly, it doesn't consider 'dnl' to be a comment and if you
| do 'dnl AC_DEFUN([FOO])' it considers that a valid definition of
| 'FOO'. It does ignore '## AC_DEFUN([FOO])' though, is this
| m4ly-correct?
|
| This means if you use AC_FOO in m4/libtool.m4 then the first file that
| happens to AC_DEFUN that will get included, even though it's defined
| with m4_define in that same file.
Gah! That has got to be a bug!! Otherwise libtool.m4 will be slowly crushed
under the weight of its old releases.
A better algorithm would be to use an existing AC_FOO macro (howsoever it is
defined) in preference to pulling in a new file of macros and all of its
dependencies?
| In other words, anything previously defined with AC_DEFUN in older
| libtool.m4 files will need to be defined with AC_DEFUN in later versions
| too, including 1.6.
|
| Here's the list of m4_define macros that need to be changed back to
| AC_DEFUN simply because they used to be defined with it[1]:
|
| AC_LIBTOOL_CONFIG
| AC_LIBTOOL_LINKER_OPTION
| _LT_AC_LANG_C_CONFIG
| _LT_AC_LANG_GCJ_CONFIG
| _LT_AC_LANG_RC_CONFIG
| _LT_AC_PROG_ECHO_BACKSLASH
| _LT_AC_SHELL_INIT
| _LT_AC_SYS_LIBPATH_AIX
| _LT_AC_TAGVAR
|
| But that's not enough, oh no, precious. You see, aclocal doesn't know
| about macros supplied by Autoconf. So if we were to define a macro in
| an older libtool.m4, say AC_PROG_EGREP, and removed it because it's now
| included in the version of Autoconf we AC_PREREQ on, aclocal wouldn't
| know about it so would pull in the older libtool.m4 simply because it
| defined it.
Good catch. Yes, we've been bitten by this before :-(
| So in summary, to stop this madness, we need to either change the
| definition of the above macro list from m4_define to AC_DEFUN or rename
| the macros and then restore the definition of AC_PROG_EGREP even if it's
| just a hack like this:
|
| # AC_PROG_EGREP
| # -
| # This is included in Autoconf, but aclocal will pull in an
| # older libtool.m4 unless we AC_DEFUN it *sigh*
| m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP], [])])
|
| [1] Or we could cheat and rename them, which is why _LT_AC_TAG_CONFIG
| (was _LT_AC_TAGCONFIG) isn't in that list.
I have been wanting to split libtool.m4 up into several files for a while to
help maintenance, and maybe reduce the size of aclocal.m4 for some of our
users. Now that libtoolize installs libtool.m4 and ltdl.m4 if they are used,
the trick might be to only show aclocal the local (libtoolize installed)
libtool macros. I think we should:
~ 1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at install
~ time
~ 2: keep copies of the latest versions only in $prefix/share/libtool/m4
~ 3: maybe we need a new $prefix/share/aclocal/ltcompat.m4 with stubs for
~ the macros you list above to keep aclocal happy?
This will, at least make the next release sane. Maybe a backport to
branch-1-5 (and branch-1-4?) is also needed to help stem the spread of madness?
Cheers,
Gary.
- --
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://www.oranda.demon.co.uk
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQE/xJFqFRMICSmD1gYRAhm/AJ4gtCg8pwqrZYHWLQxLuOrXk5jmQwCfSXeU
AqRzsqK/eMsZbZgxAZg+N/I=
=y5TA
-END PGP SIGNATURE-
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: bootstrapping CVS libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott James Remnant wrote: | On Wed, 2003-11-26 at 11:41, Gary V. Vaughan wrote: |libtool.m4 will be slowly crushed under the weight of its old releases. | | It stops us changing our AC_DEFUNs to m4_defines, yes. It wouldn't stop | us removing old macros, because we'd remove the calls to them too one | hopes. Unless they migrate into autoconf, hence the warning in bootstrap. |A better algorithm would be to use an existing AC_FOO macro (howsoever it is |defined) in preference to pulling in a new file of macros and all of its |dependencies? | | The problem is that aclocal doesn't know about m4_define, yes. Yep. | 1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at install | time | 2: keep copies of the latest versions only in $prefix/share/libtool/m4 | 3: maybe we need a new $prefix/share/aclocal/ltcompat.m4 with stubs for | the macros you list above to keep aclocal happy? | | | We wouldn't need the stubs if aclocal could only see one libtool.m4. Agreed. And 1+2 achieves this. I'll post a patch shortly. | Yet again I wish that Autoconf would learn how to keep its own macros in | order, and didn't need a tool from Automake to do it for it! The true | way to fix this is to add AC_MACRO_DIR to Autoconf, and allow it to | source files in that directory the same way it does its own macro | library. No more stuffing everything in aclocal.m4. But I digress. Akim and I (and others) have talked about this before. Unfortunately, we need to add programmatic include path munging to m4 as a prerequisite. It will happen at some point though, everyone regards aclocal as a necessary evil. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/xMt1FRMICSmD1gYRAgV6AJ9hkdBDHPpbZIrocv+P8h17EPAlUQCgwrGn sSuMMEjL/2nZzPQPdK7RRK4= =QDJk -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Non-recursive make intermediate objects
On Wed, 19 Nov 2003 16:50:23 -0600 (CST), Bob Friesenhahn [EMAIL PROTECTED] said: On Thu, 20 Nov 2003, Robert Collins wrote: subdir_objects in your automake options. Problem is, there is a design headache that makes recursive clean fail with this approach - I forget the bug #, but it's on my todo, waay down there :p. Ahhh, subdir-objects. Since this is so important to non-recursive makes, it would be useful if it was referenced in the An Alternative Approach to Subdirectories section of the documentation. Please move the clean bug up in the priority level. Automake has a non-recursive user now. :-) I suspect/believe that libtool will have some problems as well. Libtool has only one Makefile.am per configure.ac already, but I did trip over a few problems when I tried to convert M4 to a non-recursive Makefile. I'd like to convert it now, but there are some issues that I reported (maybe this is one actually). Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
1-gary-strip-target-suffix-from-default-source.patch [was Re: Default source file names]
On Tue, 18 Nov 2003 11:02:04 -0700, Kevin P. Fleming
[EMAIL PROTECTED] said:
Gary V. Vaughan wrote:
with the simpler:
~pkglibexec_LTLIBRARIES = gnu.la . traditional.la
~AM_LDFLAGS = -module
but unfortunately Automake wants to build `gnu.la' from `gnu.la.c', so the
repetitive sources declarations are necessary, unless I rename all my
source
files.
This would help me out too, I thought of the same thing.
I dusted off my copy of Programming Perl and came up with the attached
patch. I don't know whether stripping the lib prefix from {LT,}LIBRARIES
targets for a default source is also appropriate...
The problem
though is that a library is a collection of objects, it's not really a
single object (even though we're both using them that way).
But so is a program if you look at it that way. And `bin_PROGRAMS = foo'
is enough to build foo from foo.c, so it seems natural to have
`lib_LTLIBRARIES = foo.la' work similarly.
Cheers,
Gary.
--
())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker http://www.gnu.org/software/libtool \'
`
`(_~)_ Tech' Author http://sources.redhat.com/autobook
=`---d__/
1-gary-strip-target-suffix-from-default-source.patch
Description: application/unknown
[Fwd: Re: m4 from cvs, cygwin]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary V. Vaughan wrote:
|
| | ---
| | When I configured using --enable-static --disable-shared:
| |
| | make install failed (actually, make install DESTDIR=...) because libtool
| | was looking for m4.exe in .libs, even though for static builds, m4.exe
| | is in the main builddir.
| |
| | Note that libtool is not confused about this point during normal
| | builds. I believe the problem is with dlpreopen or dlopen or somesuch.
| | It's a module thing.
|
| Before I can release libtool-1.6, I want dlpreopening to work without .la
| files. It looks like cygwin is hit harder than most, but for this
| particular
| case preloaded modules should just work when I have fixed that.
Ok...
| | ---
| | When I configured using --disable-static --enable-shared:
| |
| | The build did not succeed. Apparently my fix to the global symbols
| | filter wasn't good enough. It's picking up (allowing thru) a whole
| | bunch of symbols that actually come from cygwin1.dll or crt1.o etc.
| | Symbols like __DTOR_LIST__ __RUNTIME_PSEUDO_RELOC_LIST__
| | ___w32_sharedptr _imp__m4_current_file etc.
| |
| | My fix worked in the testcase (mdemo) but...it still needs more work in
| | this torture test. [Later note: on further investigation, it MAY be
| | that somehow the old version of the export_symbols_cmds filter got used.
| | Because this behavior is exactly what I would've expected BEFORE my fix
| | was applied)
|
| Ugh. I don't know the cygwin platform well enough to help you with this
| one,
| but I will gladly apply any patches you find necessary.
I think I should probably try this again, once the libtool/ltdl inside
m4 is more closely synced with the libtool installed on my box...
| | ---
| | When I configured using --enable-static --enable-shared:
| |
| | build and install went okay. But...
| |
| | m4.exe is intrinsically linked to m4-0.dll, traditional-0.dll, and
| | gnu-0.dll, as well as to cygm4-0.dll. But only cygm4-0.dll is installed
| | in ${bindir} -- the others are in libexec/m4 -- which is not in PATH.
|
| Argh! That is definitely all wrong. libtool is supposed to dlpreload
| all of
| those modules without any dependency on the dlls. Is libtool stupidly
| preloading the import libs or something?
probably something like that. There is no testcase in libtool that
explicitly tests preloading. But...
If you configure --enable-shared --disable-static, but dlpreload
certain libraries, is libtool supposed to magically figure out that
THOSE libraries should really be built static [and NOT dynamic?] and
link against the static libs, but all the OTHER libraries should be
dynamic only and NOT static? If not, then in this case you'd still have
dll linkage.
| I have been concentrating on
| getting
| libtool into the right shape to support the next release of m4 for a
| couple of
| months,
which explains my nervousness -- as you don't have a cygwin machine
anymore. And I don't know of anybody but me who would ever just
randomly build the CVS libtool on cygwin and run the testsuite. And
since the testsuite doesn't seem to test the same stuff that m4 exercises...
And worse, it takes over 8 hours to run the testsuite as is on my
machine -- assuming I'm there to dismiss the 'dll not found' WinPopUps
that occur, by design, at several points during the test. Thanks to
Bill Gate's braindeadness, the testsuite is NOT an automated thing on
Windows. Blech.
And never mind the non-deterministic testsuite behavior. :-P
| so I should look at this again in m4 incase some of the
| configury has
| bit rotted.
perhaps. I think you're just finding the broken parts in libtool, not
in m4. Or maybe '...and in m4.'
| | rant
| |
| | 1) the autotools: most importantly autoconf, then automake, then
| | libtool, are KEY portability tools, used to help insure that stuff will
| | actually build on J-Q-random-platform.
|
| Agreed.
|
| | 2) autoconf depends on m4.
|
| Autoconf also depends on itself. It is configured with a configure.ac
| file.
Okay, perhaps I should have said that autoconf USES m4. Which means you
need a working m4 to use autoconf, in order to maintain 'Package X'.
| | 3) m4 now depends on some of the most arcane, poorly supported, dusty
| | corners of libtool.
|
| Not true. M4 depends on some of the newest, most poorly tested, fast
| changing
| parts of libtool.
Not really much consolation, there...
|
| | 4) libtool depends on automake and autoconf
| |
| | 5) which depends on m4, which...
|
| The Autoconf - M4 - Autoconf bootstrap dependency has been around
| forever.
Again, I used the wrong word. What I really meant was not dependency
exactly -- although it applies to a certain extent. What I should have
said was that effective use of libtool (when maintaining package X)
typically requires that automake be used as well -- and always requires
that autoconf be used.
|
| | Do you see the problem here? In the very near future
Re: m4 from cvs, cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cwilson wrote:
| Gary V. Vaughan wrote:
| | ---
| | When I configured using --disable-static --enable-shared:
| |
| | The build did not succeed. Apparently my fix to the global symbols
| | filter wasn't good enough. It's picking up (allowing thru) a whole
| | bunch of symbols that actually come from cygwin1.dll or crt1.o etc.
| | Symbols like __DTOR_LIST__ __RUNTIME_PSEUDO_RELOC_LIST__
| | ___w32_sharedptr _imp__m4_current_file etc.
| |
| | My fix worked in the testcase (mdemo) but...it still needs more work in
| | this torture test. [Later note: on further investigation, it MAY be
| | that somehow the old version of the export_symbols_cmds filter got
| used.
| | Because this behavior is exactly what I would've expected BEFORE my
| fix
| | was applied)
|
| Ugh. I don't know the cygwin platform well enough to help you with
| this one,
| but I will gladly apply any patches you find necessary.
|
|
| I think I should probably try this again, once the libtool/ltdl inside
| m4 is more closely synced with the libtool installed on my box...
Just sychronised CVS HEADs of M4 and Libtool.
| | ---
| | When I configured using --enable-static --enable-shared:
| |
| | build and install went okay. But...
| |
| | m4.exe is intrinsically linked to m4-0.dll, traditional-0.dll, and
| | gnu-0.dll, as well as to cygm4-0.dll. But only cygm4-0.dll is
| installed
| | in ${bindir} -- the others are in libexec/m4 -- which is not in PATH.
|
| Argh! That is definitely all wrong. libtool is supposed to dlpreload
| all of
| those modules without any dependency on the dlls. Is libtool stupidly
| preloading the import libs or something?
|
|
| probably something like that. There is no testcase in libtool that
| explicitly tests preloading. But...
I ought to try and add one in my copious spare time. :-/
| If you configure --enable-shared --disable-static, but dlpreload
| certain libraries, is libtool supposed to magically figure out that
| THOSE libraries should really be built static [and NOT dynamic?] and
| link against the static libs, but all the OTHER libraries should be
| dynamic only and NOT static? If not, then in this case you'd still have
| dll linkage.
Ah-hah! Quite right, I think you have it. I'll look into this presently.
My guess is that the --disable-static to configure should be ignored by
libtool when it is building preloaded libraries... if it were only that easy :-/
| I have been concentrating on getting
| libtool into the right shape to support the next release of m4 for a
| couple of
| months,
|
| which explains my nervousness -- as you don't have a cygwin machine
| anymore. And I don't know of anybody but me who would ever just
| randomly build the CVS libtool on cygwin and run the testsuite. And
| since the testsuite doesn't seem to test the same stuff that m4
| exercises...
I do have an old PC laying around which I could install cygwin to if it
becomes an issue. I do hope there are more people than we two that care about
libtool working on cygwin enough to at least test the alpha releases?
| And worse, it takes over 8 hours to run the testsuite as is on my
| machine -- assuming I'm there to dismiss the 'dll not found' WinPopUps
| that occur, by design, at several points during the test. Thanks to
| Bill Gate's braindeadness, the testsuite is NOT an automated thing on
| Windows. Blech.
Ah yes, how I remember those heady days :-)
| | 3) m4 now depends on some of the most arcane, poorly supported, dusty
| | corners of libtool.
|
| Not true. M4 depends on some of the newest, most poorly tested, fast
| changing
| parts of libtool.
|
| Not really much consolation, there...
I meant that they are the bits I'm working on, not the bits I've forgotten
about. That should be some consolation!
| | 4) libtool depends on automake and autoconf
| |
| | 5) which depends on m4, which...
|
| The Autoconf - M4 - Autoconf bootstrap dependency has been around
| forever.
|
|
| Again, I used the wrong word. What I really meant was not dependency
| exactly -- although it applies to a certain extent. What I should have
| said was that effective use of libtool (when maintaining package X)
| typically requires that automake be used as well -- and always requires
| that autoconf be used.
But mandating m4-2.0 is some way off. And I am sure there will be some
interrim where having m4-2.x will have advantages, but m4-1.4 will still be
sufficient...
| | Do you see the problem here? In the very near future, the autotools
| | will CEASE TO WORK AT ALL on my platform -- because the new autoconf
| | will require the new m4, and the new m4 DOES NOT WORK on cygwin.
|
| I understand your frustration, and I am just as keen as you that
| autotools
| (including m4) continue to be useful on your platform. I have made a
| point of
| statically linking all of the functionality from m4-1.4 into cvs m4, and
| giving configure options to allow package builders
[Fwd: check_LTLIBRARIES and -module ??]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [I'm forwarding this to the automake list for their consideration, I think that is where the problem lies. You might tell them what version of automake you are using. ~gary] This is part of my Makefile.am for my test directory: ~ check_PROGRAMS = test ~ check_LTLIBRARIES = libtest.la ~ test_SOURCES = ... ~ test_DEPEDENCIES = libtest.la ~ libtest_la_SOURCES = ... ~ libtest_la_LDFLAGS = -module What's above doesn't result in a shared object at all, which is what I would have expected (-module should result in something that can be dlopen()'ed according to the manual). Instead I only get an archive (.a). Modifying the last line to read ~ libtest_la_LDFLAGS = -module -rpath /silly will result in both an archive and a shared object being created. Why didn't the first work the way I wanted? Is -module broken? /M $ libtool --version ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.35 2003/11/12 18:51:58) Debian: 148 $ Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - -- Magnus Therning mailto:[EMAIL PROTECTED] +31-40-2745179 http://pww.innersource.philips.com/magnus/ OpenPGP:0x4FBB2C40 Philips, the company that I work for, does not support my idle ramblings. The opposite, it goes without saying, is true as well. - -- ~ ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ~ ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) ~ / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/u7NyFRMICSmD1gYRAj4dAJ4zL8hMAetDmNVbrXRvTQ7NSsGAKQCeMstq p7ZtNQubR8LWOPrmjN1fPwM= =Ex8p -END PGP SIGNATURE-
Default source file names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Currently m4 builds a dozen or so modules with the LTLIBRARIES primary. I had hoped that the default source file name would be set appropriately so that I could replace a whole lot of: ~pkglibexec_LTLIBRARIES = gnu.la . traditional.la ~AM_LDFLAGS = -module ~gnu_la_SOURCES = gnu.c ~... ~traditional_la_SOURCES = traditional.c with the simpler: ~pkglibexec_LTLIBRARIES = gnu.la . traditional.la ~AM_LDFLAGS = -module but unfortunately Automake wants to build `gnu.la' from `gnu.la.c', so the repetitive sources declarations are necessary, unless I rename all my source files. Can we have more realistic defaulting on names like this? Cheers, Gary. - -- ~ ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ~ ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) ~ / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/ulzQFRMICSmD1gYRAuFEAKC+Qe9cmj2boXY6teIDA5XhyiGRFACcDV1/ +wrAgZP0Pjk4qJlsXTC3/uE= =xIkf -END PGP SIGNATURE-
Re: mechanics style
Alexandre Duret-Lutz wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary I got the ball rolling for this oft discussed macro by putting it in Gary autoconf and using it in libtoolize. My perl fu is insufficient to the Gary task of supporting it from automake (aclocal etc). Please send a patch Gary before the next rev of automake, so that aclocal traces Gary AC_CONFIG_MACRO_DIR and automatically adds an appropriate -I to its Gary search path. Hmm, you can't trace until you now all the -I's. See: http://mail.gnu.org/archive/html/automake/2003-09/msg00112.html So I think right now the ball is in M4's court, not Automake's :) Ah yes, well reminded. I had entirely forgotten about that. One slice of humble pie please :-) Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: mechanics style
On Sat, 8 Nov 2003 22:22:40 +, Patrick Welche [EMAIL PROTECTED] said: .. oh, and, what do you do about aclocal -I mym4dir? The automake doco mentions setting ACLOCAL_AMFLAGS = -I mym4dir, but how does that tie in with AC_CONFIG_MACRO_DIR(mym4dir)? I got the ball rolling for this oft discussed macro by putting it in autoconf and using it in libtoolize. My perl fu is insufficient to the task of supporting it from automake (aclocal etc). Please send a patch before the next rev of automake, so that aclocal traces AC_CONFIG_MACRO_DIR and automatically adds an appropriate -I to its search path. Until then, this is just a wart! Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: Gary V. Vaughan wrote: The only way I can think of doing this is with an install-exec-hook that removes installed libraries if INSTALL_LIBS was not set: if !INSTALL_LIBS install-exec-hook: $(MAKE) $(AM_MAKEFLAGS) uninstall-pkglibLTLIBRARIES endif But this depends on an undocumented target. Better to put the modules in a separate dir with their own Makefile.am, and call that Makefile's uninstall rule in the same way. Yuck... that means my users will see the libtool --mode=install messages and ldconfig runs for all 30+ modules, then they'll all get removed. For now I think I can live with the files getting installed and the users just knowing that they're not necessary for the application to be used. Yeah, that is pretty sucky. What about installing the modules to a bogus directory (in the build tree?) and then removing that directory? if !INSTALL_LIBS pkglibdir = $(top_builddir)/_noinst install-exec-hook: @echo pruning statically linked modules rm -rf $(pkglibdir) endif Or, if you give the modules their own Makefile.am, you might be able to redefine INSTALL and mkinstalldirs to neuter the install rules: if !INSTALL_LIBS INSTALL=: mkinstalldirs=: endif Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: Gary V. Vaughan wrote: Actually, you *do* need to install the libraries even if they are linked into the program statically because libltdl looks up the pseudolibrary (.la) in the module directory to get metadata about (even preloaded) modules. Fixing this is on the TODO list, but it is quite a big job and probably won't be fixed soon. Well, now that you've seen my messages on the libtool list you know that I'm not lt_dlopen-ing the .la files at all (unless they were built shared), but rather scanning the lt_preloaded_symbols list directly and using the names I find there. So in my case I don't need the .la files when the libraries were built statically, unless there's something else that I'm missing. I'd really like my users to be able to create a static binary and be able to copy it around without needing any support files for it to function properly. Is there a way to get this AM_CONDITIONAL logic to do what I'm asking? Completely untested, but have you tried: pkglib_LTLIBRARIES = noinst_LTLIBRARIES = if INSTALL_LIBS pkglib_LTLIBRARIES += $(LIBLIST) else noinst_LTLIBRARIES += $(LIBLIST) endif ? HTH, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: Gary V. Vaughan wrote: Completely untested, but have you tried: pkglib_LTLIBRARIES = noinst_LTLIBRARIES = if INSTALL_LIBS pkglib_LTLIBRARIES += $(LIBLIST) else noinst_LTLIBRARIES += $(LIBLIST) endif Just tried it, same results, automake reports each module in LIBLIST as already going to be installed in 'noinst'. In fact, I even tried changing noinst_ to lib_, and now it reports already going to be installed in 'lib'. Argh! No wait, I am a dufus. A noinst_LTLIBRARY is always a convenience library, whereas a pkglib_LTLIBRARY is affected by configure --disable-shared etc. Even if you somehow got past the syntax problems, the semantics are all wrong anyhow. The only way I can think of doing this is with an install-exec-hook that removes installed libraries if INSTALL_LIBS was not set: if !INSTALL_LIBS install-exec-hook: $(MAKE) $(AM_MAKEFLAGS) uninstall-pkglibLTLIBRARIES endif But this depends on an undocumented target. Better to put the modules in a separate dir with their own Makefile.am, and call that Makefile's uninstall rule in the same way. Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: automake-1.7.8/autoconf-2.57/libtool-1.5 in configure.ac (after all the libtool-related macros but before AC_OUTPUT): AM_CONDITIONAL(INSTALL_LIBS, test x$enable_shared = xyes) in Makefile.am: ... LIBLIST = src/lib/libnALFS.la LIBLIST += src/handlers/alfs.la LIBLIST += src/handlers/build.la LIBLIST += src/handlers/chroot.la LIBLIST += src/handlers/configure.la LIBLIST += src/handlers/copy.la LIBLIST += src/handlers/execute.la ... (more of the same) if INSTALL_LIBS INSTALL_LIBLIST = $(LIBLIST) else INSTALL_LIBLIST = endif if !INSTALL_LIBS NOINST_LIBLIST = $(LIBLIST) else NOINST_LIBLIST = endif pkglib_LTLIBRARIES = $(INSTALL_LIBLIST) noinst_LTLIBRARIES = $(NOINST_LIBLIST) With this construction, automake complains src/handlers/alfs.la is already going to be installed in 'noinst' (for each library). All _SOURCES/_LDFLAGS/etc. variables for these libraries appear after this set of lines (I have tried them before and after, no difference). I have tried setting pkglib_LTLIBRARIES and noinst_LTLIBRARIES _directly_ inside the conditional (instead of using intermediate variables), but that didn't help. This is about the fourth attempt at constructing this logic; I need to _always_ build these libraries, but only install them if the user asked them to be built shared (for a static build, they will be subsumed into the main binary and don't need to be installed). Am I missing something? This seems to be a valid thing to try, but I can't get automake to accept it. Actually, you *do* need to install the libraries even if they are linked into the program statically because libltdl looks up the pseudolibrary (.la) in the module directory to get metadata about (even preloaded) modules. Fixing this is on the TODO list, but it is quite a big job and probably won't be fixed soon. Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: Copying vs m4_including macro files
Alexandre Duret-Lutz wrote: On Mon, Sep 22, 2003 at 06:12:50PM +0100, Gary V. Vaughan wrote: [...] I was hoping to remove acinclude.m4 and use m4_include in aclocal.m4 by switching to CVS automake, but currently the contents are still copied to aclocal.m4 if they are not in the same directory as configure.ac. Wherever I put libtool.m4, 8 sibling directories still get a copy of the macros instead of an m4_include. Idea 1: Do not use aclocal.m4 in these subdirectories. Simply add m4_include([../aclocal.m4]) and maybe m4_include([../ltdl.m4]) at the top of all these configure.ac. Not an option since all of the automake macros need to be copied in for configure.ac to be expandable to a working configure script :-( Or alternatively you can build your own aclocal.m4 containing these one or two statements. Simply do not run aclocal. Automake contains code to disable the rebuild rule for aclocal.m4 when it hasn't been generated by aclocal (I'm not sure how well tested this is, but if it doesn't work this is certainly something we should fix). Same problem here: aclocal knows about the macros it needs to pull in (aside from libtool.m4 and ltdl.m4) so that the other autotools can be run. Idea 2: Since most of these subdirectories are used by the test suite, maybe it could make sense to build configure/aclocal.m4/Makefile.in/etc. on the user's host with the installed tool. Using a wider range of tools versions is likely to help to catching incompatibilities. I want users of m4 to be able to `make check' without having the autotools chain installed. I presume the main drawback is that not building these configury files makes it harder to distribute these subdirectories? That's true, but I'm worried about the testsuite not running at install time, and about dragging 21 200k copies of libtool.m4 around in the tarball. Actually acinclude.m4 isn't needed with aclocal-1.7a, so I can reduce it to 11 copies now. Also it is easier to check that the correct libtool.m4 is being used by autoconf when aclocal.m4 can m4_include([../libtool.m4]), than when the entire contents are copied into aclocal.m4. I think that it is wrong for aclocal to copy macros from AC_CONFIG_AUX_DIR directories, if the directory is listed there, then that directory will need to be shipped, or `make dist' won't work. If the directory is shipped, then it is okay for aclocal to m4_include files from it. I agree, but I also think we shouldn't incite users to lump .m4 files with auxiliary build tools. Many projects have separate m4/ and tools/ (or config/ or aux/, pick your favorite) directories, so it would be better if we can solve this problem without merging these directories. Good point. Aside: You can't use a file or directory called AUX (or COM for that matter) on FAT32 filesystems!! Maybe we could simply revisit the way aclocal decides whether a macro is local. Right now paths starting with /, c:/, ./../, or ../ are not considered local. But most of the time ./../* and ../* files _are_ distributed. I don't know how frequent it is that people use `aclocal -I ../somedir' to build aclocal.m4 and yet do not distribute ../somedir. Maybe we should consider ./../* and ../* files as local, and let people write `aclocal -I `pwd`/../somedir' when it is untrue. It is definitely wrong (from a don't hide files from the user point of view) to not ship special macros needed by configure.ac, as the user will never be able to regenerate the build files from the dist tarball. Therefore I think it is fine to consider relative directories specified with -I to be project local. Alternatively we could take any leading `./' as an indication that the files should be local, so that one would just write `ACLOCAL_AMFLAGS = -I ./../m4' instead of `ACLOCAL_AMFLAGS = -I ../m4' when ../m4 is to be considered local. Any opinion? That feels like a hack. There are better ways to do it. [*] BTW, I recall a discussion with Akim (not sure it was done on a mailing list) about a future version of aclocal (actually we were talking about an Autoconf-supplied equivalent) which should copy third party macros from /usr/share/aclocal/ to a directory local to the project before m4_including them from aclocal.m4. The question was in which directory should these files be copied, and the answer was we needed an AC_CONFIG_M4_DIR macro to specify this. Maybe it's time to introduce this macro. Even though .m4 files would not be copied yet, it would be useful to hint aclocal that a directory should be considered local, without constraining people to use aux_dir for .m4 files. I've touched upon the same subject with Akim. Infact he prototyped the idea with make rules in CVS m4 a couple of years ago :-) I think that it is a fine goal. Actually, developing Autoconf, Automake and Libtool in their own packages makes less and less sense as their interdependencies grow. One day I'd like to see a combined Autotools development
Re: Copying vs m4_including macro files
Akim Demaille wrote: On Wed, Sep 24, 2003 at 02:19:06PM +0200, Akim Demaille wrote: At the origin I was considering that AC_CONFIG_M4_DIR was automatically passed to m4 as a -I, so instead of m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]). Isn't there a chicken'n'egg problem? How can you trace for AC_CONFIG_M4_DIR if you need the result to run m4 properly? Right, there was something like that :) With m4-2.0 (it is too different to 1.4 to be called 1.5), you (or I) could write a builtin for include path mangling. Provided AC_CONFIG_M4_DIR([config]) expanded to (say) m4_prepend_search_path([config]), and that happened before the first m4_include, it would work. I'd quite like to sort out m4's search path issues in the near future... patches gratefully accepted :-) Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Copying vs m4_including macro files
Gentle Reader: I want to minimise duplication of macros among directories in CVS libtool. Libtool-1.5 was released with libtool.m4 and ltdl.m4, but due to idiosyncracies in the build process, these files were copied to acinclude.m4 in no less than 10 directories. Running aclocal then copied these to aclocal.m4 in each directory, for a total of 21 copies of (200k) libtool.m4 and 5 copies of (13k) ltdl.m4 :-( I was hoping to remove acinclude.m4 and use m4_include in aclocal.m4 by switching to CVS automake, but currently the contents are still copied to aclocal.m4 if they are not in the same directory as configure.ac. Wherever I put libtool.m4, 8 sibling directories still get a copy of the macros instead of an m4_include. I think that it is wrong for aclocal to copy macros from AC_CONFIG_AUX_DIR directories, if the directory is listed there, then that directory will need to be shipped, or `make dist' won't work. If the directory is shipped, then it is okay for aclocal to m4_include files from it. I would supply a patch, but my perl-fu is inadequate to the task. What I think needs to happen is write_aclocal() should not consider AC_CONFIG_AUX_DIR directories to be `outside the project' when it decides what to do about a macro. aclocal doesn't currently collect macro traces from configure.ac, and pasting the code from automake seemed like overkill. Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: Running libtoolize
On Fri, Oct 26, 2001 at 03:59:29PM +0200, Akim Demaille wrote: I don't think it is the job of Automake to run libtoolize when autoreconf IMHO. I'm in favor of removing this. Agreed. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: setting additional libtool runtime variables
On Sun, Oct 14, 2001 at 10:03:38PM -0400, [EMAIL PROTECTED] wrote: Is there a way to tell libtool that it needs to set some additional runtime variables in addition to LD_LIBRARY_PATH when trying to test run an executible before its installed? I have some data files and the path gets built into the binary, but can be overridden with an environment variable. You could use a wrapper script that sets the environment up and then execs the real binary... CVS autoconf does this in the tests dir. Or you could set Automake's TESTS_ENVIRONMENT (sp?) variable in your Makefile.am. HTH, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL
On Fri, Sep 21, 2001 at 12:49:00PM -0500, Raja R Harinath wrote: Jens Krüger [EMAIL PROTECTED] writes: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden Can you translate the message to English? /bin/sh: cd: SoNXLakeShore: File or directory not found Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: P.S. Automake 1.4f is broken
On Sun, Sep 09, 2001 at 04:58:39AM -0700, Bruce Korb wrote:
Gary V. Vaughan wrote:
Ah, okay. I thought you meant AutoGen was hosed.
It is, too. First, snprintfv/config/depcomp couldn't be found during
a make distcheck. Since it was a generated file, I added it to the
EXTRA_DIST for that directory.
As I understand it (which may be not very much -- I held out on
Automake 1.4 until a feww weeks ago) depcomp should not be needed by
an installer, it used to generate dependencies for the developer,
which are included into the Makefile.in's rolled into the distribution
tarball with `make distcheck'.
Then there are these:
automake: Makefile.am: installing `./COPYING'
Use of uninitialized value in string eq at /usr/local/bin/automake line 5192.
I have been getting this in the libltdl bootstrap sequence since I
upgraded to 1.5, but haven't looked any deeper since it doesn't seem
to affect the rest of the build. I'm glad it is not just me going
insane :-D Besides I only have a Perl-Fu white belt, so much the
detail is beyond my ken.
Use of uninitialized value in hash element at \
/usr/local/bin/automake line 1751.automake: configure.in: installing
`config/depcomp'
I haven't seen this one before...
sub derive_suffix
{
my ($source_ext) = @_;
# FIXME: hard-coding `o' is a mistake. Doing something
# intelligent is harder.
while ($extension_map{$source_ext} eq '' ### line 5192
$source_ext ne 'o'
defined $suffix_rules{$source_ext})
{
$source_ext = $suffix_rules{$source_ext};
}
sub handle_single_transform_list ($$$@)
{
my ($var, $derived, $obj, @files) = @_;
my @result = ();
my $nonansi_obj = $obj;
$nonansi_obj =~ s/\$U//g;
my %linkers_used = ();
foreach (@files)
{
[error test]
next if ! /^(?:(.*)\/)?([^\/]*)\.(.*)$/;
my $full = $_;
my $directory = $1 || '';
my $base = $2;
my $extension = $3;
[comment]
my $renamed = 0;
my ($linker, $object);
$extension = derive_suffix ($extension);
my $lang = $languages{$extension_map{$extension}}; ### line 1751
and:
Making distclean in .
make[3]: Entering directory `/home/bkorb/ag/ag/autogen-5.2.10/=build/snprintfv'
[...]
make[2]: Entering directory `/home/bkorb/ag/ag/autogen-5.2.10/=build'
rm -f Makefile stamp-h stamp-h[0-9]*
rm -f config.h
rm -f TAGS ID
make[2]: Leaving directory `/home/bkorb/ag/ag/autogen-5.2.10/=build'
rm -f config.status config.cache config.log
make[1]: Leaving directory `/home/bkorb/ag/ag/autogen-5.2.10/=build'
Error: files left after distclean
make: *** [distcheck] Error 1
Ah. I see the problem. Schizophrenic builds do not work because
there is no way to pass VPATH through to scripts and programs
that build targets. VPATH is a command line feature.
Aha! I have been getting reports that CVS libtool no longer builds
correctly with builddir != srcdir. I've burnt a couple of hours
trying to figure out why libltdl/libtool doesn't arrive in the build
tree. I'll bet it is the same problem, and that it will work if I
downgrade to Automake 1.4-p5 again...
I fixed
this problem by having builddir != srcdir builds sym-link
the source tree into the build tree. Someone in automake land
decided to verify that make distclean was successful by looking
for files in the build tree and accepting the sym-links as
files:
cd $(distdir)/=build \
../configure --srcdir=.. --prefix=$$dc_install_base \
[...] \
$(MAKE) $(AM_MAKEFLAGS) distclean \
rm -f $(distdir).tar.gz \
(test `find . -type f -print | wc -l` -eq 0 \
|| (echo Error: files left after distclean 12; \
exit 1) )
I think that VPATH is a broken concept. This final test
needs to be a WARNING, not an error. Automake is broken.
VPATH is good in principle, but it is always hard to support. In
build tools as well as development projects. But I agree with your
diagnosis.
For gnuprog2 we are very much on the bleeding edge I'm afraid.
Is there a compelling reason for using bleeding edge?
I'm quite tired of the blood letting, I must say.
For AutoGen, no reason at all. Autoconf-2.13, Automake-1.4p5 and
Libtool 1.4.2 will be just fine. [[I have delayed 1.4.2 far 24 hours
because I think I have found a more elegant solution to the Solaris
problem, that requires more testing]]
That kills my last release. *sigh*.
Sorry about that =(O|
M4-1.4q is available from savannah in parallel with libtool.
I need this, too?
To perform a full build of gnuprog2, yes. For AutoGen, 1.4 is fine.
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker http://www.gnu.org/software
Re: EXTRA_DIST = config.h.in
On Sunday 01 July 2001 5:31 pm, Bruce Korb wrote: Tom Tromey wrote: Bruce == Bruce Korb [EMAIL PROTECTED] writes: Bruce Why is this now necessary? It did not used to be. Is this Bruce intended? Is there an upgrading README file kicking around? It is probably a newly introduced bug. You don't mention what version you are using though. Could you submit a full bug report? That would include the version number, $ automake --version automake (GNU automake) 1.4-p4 preferably a short example, and cvs get autogen cd autogen sh config/bootstrap make make check make distcheck an explanation of what you expected and what actually happened. I expected that since prior versions of automake automatically distributed config.h.in without my having to tell it to do so, then it would also distribute config-h.in in the same manner. However, instead I hand edited (not yet under CVS) the Makefile.am and snprintfv/Makefile.am files to add config-h.in to the EXTRA_DIST sources. configure.in is using AC_CONFIG_HEADERS (the autoconf-2.50 flavour of AC_CONFIG_HEADER) instead of AM_CONFIG_HEADER. automake-1.4-p4 doesn't spot misuse of AC_CONFIG_HEADERS (I'll check in a fix presently incase I release p5), but changing to AM_CONFIG_HEADER causes config-h.in to be distributed as before. CVS HEAD already diagnises AC_CONFIG_HEADEERS correctly. I guess I screwed up AutoGen's autoconf-2.50 upgrade (I'll check in a fix presently), sorry. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: automake 1.4 : --copy problem?
On Tuesday 26 June 2001 10:34 am, David Lee wrote: On Mon, 25 Jun 2001, Gary V. Vaughan wrote: This is a long standing bug that has been fixed in release versions since automake-1.4-p1. You can always find the latest automake release at ftp://ftp.gnu.org/gnu/automake/ or any of the gnu mirrors. Many thanks for your reply, which is appreciated. I realise this bug won't affect end-users, who won't see automake. But some of the developers are (understandably) a little concerned about the message. They are working on fixed systems; upgrade to later versions of automake may be impractical (unless of strategic importance). So could you confirm: 1. that this bug is basically usually harmless (indeed, is expected); 2. the action (copying those files into place) is actually successful; 3. its success can be confirmed by repeating the command, which should produce no errors. Yup, I can confirm all 3. Might you have some sort of statement in existence that we could beg, steal or borrow, to reassure developers on our project? Not here, sorry. Many thanks again. You're welcome, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: automake 1.4 : --copy problem?
Hi David,
This is a long standing bug that has been fixed in release versions since
automake-1.4-p1. You can always find the latest automake release at
ftp://ftp.gnu.org/gnu/automake/ or any of the gnu mirrors.
Cheers,
Gary.
On Monday 25 June 2001 6:07 pm, David Lee wrote:
Background: we are trying to autoconfiscate the linux-ha package (for
high availability work).
With automake 1.4, I try
automake --foreign --add-missing --copy
and get:
automake: configure.in: installing `./install-sh'
error while copying
automake: configure.in: installing `./mkinstalldirs'
error while copying
automake: configure.in: installing `./missing'
error while copying
Despite these alarming-looking errors, these three copied files still end
up in place OK: repeating the same command is then OK.
If I leave off the --copy, so that it creates symlinks instead of copies,
it is OK:
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
and I end up with three symlinks, as expected.
Looking at the automake in my system, I see at line 6910:
elsif (! system ('cp', $am_dir . '/' . $file, $errfile))
{
$suppress = 0;
$trailer = \nerror while copying\n;
}
I suspect that the ! should be absent (perhaps some confusion over the
opposite numeric OK/fail conventions in perl vs. UNIX return codes).
I have the feeling this must be a very well-known problem. Is it? If so,
can you give me any background to it.
It is possible that we can live with the problem for the time being
(especially as work on the next version of automake is so well in hand).
But information about it would be exceedingly useful, and any reasonable
solutions would be a nice bonus.
Thanks in advance.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk,_())
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `
`(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: What version of autoconf is required for automake-1.4f?
On Saturday 23 June 2001 12:38 am, Clark Rawlins wrote: Tom, Thank you for your help. I am sorry if these questions are FAQs if so please direct me to the appropriate documentation. http://sources.redhat.com/autobook After installing automake-2.14f in /usr/local I am getting an error messages when running aclocal: aclocal: configure.in: 10: macro `AM_PROG_LIBTOOL' not found in library All I did when I installed automake-2.14f was the usual ./configure make su make install Are there some configuration settings I should have set for configure? I didn't see any in the README INSTALL or in ./configure --help All of the packages intalled by your distro that support aclocal (gettext, gtk, libtool etc) will have put their macros in /usr/share/aclocal, but you have installed automake to /usr/local so it is looking in /usr/local/share/aclocal. If you don't mind upsetting your package manager, the following will work (as root): $ cp -f /usr/local/share/aclocal/* /usr/share/aclocal $ rmdir /usr/local/share/aclocal $ ln -s /usr/share/aclocal /usr/local/share/aclocal More properly, use your package manager to uninstall the distributed automake package, and reinstall your version, but this time configured with --prefix=/usr (preferably after making a package from it). Cheers, Gary. On Fri, Jun 22, 2001 at 11:12:20AM -0600, Tom Tromey wrote: Clark Is autoconf (v 2.13) installed in /usr compatible with Clark automake 2.14f installed in /usr/local? Yes. Tom -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: What version of autoconf is required for automake-1.4f?
On Friday 22 June 2001 11:40 am, Clark Rawlins wrote: Is autoconf (v 2.13) installed in /usr compatible with automake [[1.4f]] installed in /usr/local? Technically: yes. However, installing the autotools into different $prefix'es can lead to complications (if a package tries to install some autoconf macros into $prefix/aclocal for example -- where do they go, and will automake be able to find them?). Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: override default CXXFLAGS
On Friday 22 June 2001 11:45 am, Rusty Ballinger wrote: I set the CXXFLAGS via AM_CXXFLAGS in Makefile.am. the relase version should have no -g flag... but there is a default CXX_FLAGS variable in Makefile which has always the -g flag. how can I remove this one? One way is to set it in the environment when running the configure script: $ CXXFLAGS= ./configure --with-various-args If you just want to get rid of the debug symbols, do it at install time: $ make install-strip Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: missing does not support configure.ac in CVS or in 1.4-p4
On Monday 11 June 2001 6:17 am, Kevin Dalley wrote: Martin Dickopp [EMAIL PROTECTED] reported noticed that the file missing does not support configure.ac in either the latest CVS release or in 1.4-p4. This problem is limited to echo statements, but should still be fixed. Here is Martin's suggested patch: Thanks. Applied on branch-1-4. If there is an automake-1.4-p5, this will be in it! Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
[ANNOUNCE] New stable automake release: automake-1.4-p4
My very own brown paper bag release... I have just uploaded patch release 4 from the automake-1.4 maintenance branch. This time configure.ac from Autoconf-2.50 is supported properly. The tarball is available now from: ftp://ftp.gnu.org/gnu/automake/automake-1.4-p4.tar.gz Or as a a diff or xdelta against the previous release: ftp://ftp.gnu.org/gnu/automake/automake-1.4-p3-1.4-p4.diff.gz ftp://ftp.gnu.org/gnu/automake/automake-1.4-p3-1.4-p4.tar.xdp.gz ...and shortly from all GNU mirror sites. Or else directly from anonymous CVS using the tag `Release-1-4-p4'. The changes in this release since version 1.4-p3 are as follows: * Deal with configure.ac as well as configure.in -- this time for real! * The version numbering system now allows three point version numbers, such as 1.4.4, without thinking they are alpha release numbers. Unless you use configure.ac, or 3 point release numbers there is no need to upgrade to this release. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
[ANNOUNCE] New stable automake release: automake-1.4-p3
Yet another interruption to your regularly scheduled posts with a brief news flash: I am proud to present patch release 3 from the automake-1.4 maintenance branch. The main purpose of this release is to add better compatibility with Autoconf-2.50. It is available now from: ftp://ftp.gnu.org/gnu/automake/automake-1.4-p3.tar.gz Or as a a diff or xdelta against the previous release: ftp://ftp.gnu.org/gnu/automake/automake-1.4-p2-1.4-p3.diff.gz ftp://ftp.gnu.org/gnu/automake/automake-1.4-p2-1.4-p3.tar.xdp.gz ...and shortly from all GNU mirror sites. Or else directly from anonymous CVS using the tag `Release-1-4-p3'. The changes in this release since version 1.4-p3 are as follows: * Deal with configure.ac as well as configure.in. * Don't complain if `version.texi' is included in multiple places. Please download, compile, install and enjoy. We now return you to your regular programming... Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: cygwin libtool breakage
On Monday 04 June 2001 12:41 pm, Robert Collins wrote: - Original Message - From: Gary V. Vaughan [EMAIL PROTECTED] To: Robert Collins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 04, 2001 11:25 AM Subject: Re: cygwin libtool breakage On Saturday 02 June 2001 5:43 pm, Robert Collins wrote: the first failure, demo-make.test fails because ar is called with no object files. I have a failure (among 10) against the last demo-make.test (following demo-shared.test)... but I guess you are running with the patches you posted earlier which fix some of the failures I see. freshly setup.exe'ed cygwin-1.3.2 and a freshly pservered libtool HEAD, I get the following: gary@MALACHI ~/libtool$ export CC=gcc I suspect my nothaving run this as much as anything. ltmain was working for me on a test hellolib pacakge. I was surprised by this myself; without it config.sub runs without a compiler and the cygwin test fails. I think it is a bug in libtool that cygwin is tested for before the compiler is checked. I want to spend some time on cygwin friendlyness in libtool real soon now -- hopefully before 1.4.1, though I won't hold back that release for a lack of it. This is what I get now: - unable to make hell-static -. I'm running automake CVS HEAD - could that be related? [[snip]] = Configuring in ../demo (prefix=/usr/src/libtool/build/tests/_inst) with --disable-shared [[snip]] checking dependency style of gcc... cp: /usr/src/libtool/tests/../demo/../depcomp: No such file or directory /usr/src/libtool/tests/../demo/configure: cannot open ./depcomp: no such file none Looks like an automake issue to me -- I am running 1.4, and have no problem. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
Re: [PATCH] fix install on cygwin with shared libraries
On Sunday 03 June 2001 4:21 am, Robert Collins wrote: I figured that changing the call to libtool to use foo not foo.exe would be a bad thing in some cases... so I altered libtool to check for foo as a libtool program if it is given foo.exe but foo.exe does not exist. The patch libtoolinstalloncygwin.patch implements this. This is something I have been meaning to fix for a long time. I can't speak for the automake part of your fix, but I like the libtool part and will apply it in time for 1.4.1 and 1.4b, as soon as the MLB merge is complete. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/
