Re: [patch 02/19] 284-gary-report-macro-files-for-aclocal.diff Queue
Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf! > * Gary V. Vaughan wrote on Wed, Oct 12, 2005 at 05:28:20PM CEST: > OK, please apply. Thanks for redoing. Will do. Just waiting on a verdict on 277 so I can do them in the same order that I've tested them, to avoid any further hiccoughs. > By the way: please fix your patch mailing system not to ever send in > format=flowed again. I had to apply all your redone patches manually. > :-/ Sorry, was pasting from an ssh shell on one machine into a Thunderbird window on another machine. I'll scp and attach next time. >>from Gary V. Vaughan <[EMAIL PROTECTED]> >>* libtoolize.m4sh: Copying just libtool.m4 for hand maintained >>aclocal.m4 doesn't work. List all required files in that case, >>using the files from installed libltdl if available. Also, list >>the additional files required when using libltdl. >>Reported by Patrick Welche <[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
Re: darwin: mix up of .dylib and .bundle
> Christoph Egger wrote: > > > > Attached. > > libgii-debug-experimental.output.gz is the whole subdirectory > > as I sent in my last mail with debug info. > > libgii-debug-experimental.output2.gz is the failing libtool link > > line with debug info. > > Doh! In a directory named ggbundle, > file -L /path/to/with/ggbundle/in/it | grep bundle will return true! > > Let me look into a patch, probably testing for 'Mach-O bundle' is better > than testing for 'bundle'. I've attached a patch, which fixes this bug. I also added comments (two lines) which explains what it does and why. libtool no longer needs to worry about any directory names. Please review and apply. -- Greetings, Christoph Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ltmain.m4sh.diff Description: Binary data
libtoolize weirdness (after 285-gary)
Hi Gary, Sorry for the terse bug report, I hope this is understandable: cat >configure.ac <<\EOF AC_INIT(a,1,b) AC_CONFIG_MACRO_DIR([ltdl/m4]) AC_CONFIG_SUBDIRS(ltdl) AM_INIT_AUTOMAKE AC_WITH_LTDL(ltdl) AC_LIB_LTDL(ltdl) AC_PROG_LIBTOOL AC_CONFIG_FILES(Makefile) AC_OUTPUT EOF libtoolize --ltdl=ltdl # this is fine aclocal -I ltdl/m4 libtoolize --ltdl=ltdl The second `libtoolize' invocation now also asks me to | libtoolize: You should add the contents of `ltdl/m4/ltversion.m4' to `aclocal.m4'. It seems to compare the serial 7 from aclocal.m4:AM_CONDITIONAL with the serial 2132 from ltdl/m4/ltversion.m4. Cheers, Ralf
Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Thu, Oct 13, 2005 at 06:40:59PM CEST: > Ralf Wildenhues wrote: > >Do you want the (non)recursive/subproject info as argument to > > LT_WITH_LTDL > >or > > LT_CONFIG_LTDL_DIR > > Eek! That leaked in from the ancient past. My first implementation tried > to put the mode argument in LT_WITH_LTDL, but for various reasons that > turned out to be untenable, so I moved it to LT_CONFIG_LTDL_DIR (which > actually is conceptually nicer anyway). I've removed all evidence of > the earlier implemention for sure this time! Thanks! > >I have found more nits, see inline. Also, please remember: > >- adjust doc plus makefiles for whatever you agree on wrt. *_LTLIBRARIES > > DEFS, AM_CPPFLAGS, AM_CFLAGS: `+=' vs `='. > > Done. Although I've moved the contents of DEFS into AM_CPPFLAGS to reduce > the number of magic variables a little. OK, even better, although I have a hard time seeing whether this works in all cases.. > >And please actually do the commit only together with the followup > >patches needed to implement the functionality, so CVS HEAD is not in > >broken state for long. Thank you. > > Actually, this patch doesn't break libtool at all... the testsuite still > passes, it's just that recursive mode isn't yet implemented. D'oh. Thank you, I overlooked that! > >Now, how's that gonna work if the user uses a name different from > >`libltdl/' as subdir? The paths in `libltdl/Makefile.inc' are pretty > >hardcoded to start with `libltdl/'! > > > >No need to change the implementation IMHO, but it may be good to adjust > >above paragraph to match the limitation to firmly state: if you use > >nonrecursive, that subdir better be named `libltdl' and nothing else! > > I had started a patch to substitute in the correct value as libtoolize > copied Makefile.inc into the project tree. But figure that is icing. > I'd forgotten that you *must* use libltdl for nonrecursive. Good catch, > thanks! I'll also add to [298] a note that a LIBOBJDIR capable Automake > and Autoconf are required for this mode to work as it stands (as per > your review of that patch) -- we certainly have room to tweak libtoolize > to replicate the trick libtool itself uses to workaround the problem > later... OK, fine with me. * Gary V. Vaughan wrote on Fri, Oct 14, 2005 at 05:34:28PM CEST: > Tweaked this patch slightly to allow for the next one to work whether > or not SUBDIR_LIBOBJS are supported by the user's autotools. Okay to > commit? I have a couple of gripes with it: - First, LTCOMPILE is not published interface by Automake, - Second, you kill dependency tracking for the LTLIBOBJS, Considering this, maybe this is too high a price to pay for gaining unchanged AM_CPPFLAGS, DEFS, and AM_LDFLAGS. What do you think? Sorry for not thinking enough about this before, but now that I see this, I believe it needs to be addressed. A couple of trivial nits: - I believe SUBDIR_LIBOBJS is too generic a name to be used in third-party Makefiles. (Prepend LT_ or LTDL_ or so) - list libltdl/Makefile.inc before libltdl/Makefile.am in ltdldatafiles > Incidentally, this also removes the troublesome '## %%% BEGIN' magic from > Makefile.am. Nice! Could you please repost the patch without format=flowed, so I can apply it cleanly. Thank you. I'm seeing weirdnesses with libtoolize but want to make sure they are not from me messing up the merge. Cheers, Ralf > from Gary V. Vaughan <[EMAIL PROTECTED]> > * configure.ac: Move SUBDIR_LIBOBJS check from here... > * libltdl/m4/ltdl.m4 (_LT_CHECK_SUBDIR_LIBOBJS: ...to here. > (LT_INIT): Adjust. > * libltdl/Makefile.inc: New file, factored out of Makefile.am for > use in non-recursive libltdl installations. > * Makefile.am: include it. > (libltdl/Makefile.am): Adjust to build from the new > libltdl/Makefile.inc. > * bootstrap: Adjust. > * doc/libtool.texi (Invoking libtoolize): Document the new modes > and libtoolize option to select them. > * libtoolize.m4sh: Parse new options, --nonrecursive, --recursive > and --subproject. Install the appropriate files with --ltdl > according to the selected mode. > (func_scan_files): If --subproject, --recursive or --nonrecursive > options were not given, use the value from LT_CONFIG_LTDL_DIR; if > a mode was given, and there is also an argument to > LT_CONFIG_LTDL_DIR, ensure they are the same. > * NEWS: Updated.
Re: [patch 03/19] 285-gary-diagnose-missing-LT_WITH_LTDL.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Wed, Oct 12, 2005 at 10:47:53PM CEST: > > > Now that I see this: Please remove these two lines, or make them as > > little intrusive as branch-1-5 was: > > Actually, it already triggers under fewer circumstances than 1.5.x! > > > grepped for '^AC_PROG_RANLIB'. > > Rationale: a `libtoolize' that'll bug me every time because of > > > > m4_if([I_USE_LIBTOOL], > > [AM_PROG_LIBTOOL], > > [AC_PROG_RANLIB]) > > > > will make me not listen to it. Besides, I *could* be using libltdl > > as subpackage (and thus `libtoolize --ltdl') but not wanting to use > > libtool in the parent package. > > But I take your point. This patch only runs the test when --ltdl is > not being used. OK. Fine, please apply! I've found another bug in the related area; but since I believe it existed before this and the previous patch, I'll post it separately. Cheers, Ralf > Index: libtool--devo--1.0/ChangeLog > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Move the consistency checks... > (func_check_macros): ...into here. Also suggest LT_WITH_LTDL if > appropriate.
Re: [patch 02/19] 284-gary-report-macro-files-for-aclocal.diff Queue
Hi Gary, * Gary V. Vaughan wrote on Wed, Oct 12, 2005 at 05:28:20PM CEST: > Ralf Wildenhues wrote: > > >What I meant in the other thread we were discussing this: add right here > >something like this: > >func_echo "or instead follow the advice about > >\`AC_CONFIG_MACRO_DIR' below." > > > >since the macros exist below $ltdldir/m4 anyway.. > > Oh, okay. Not quite that simple as the 'following advice' may not be > printed, depending on the state of various flags set by scanning and > command line options. Here is a replacement patch that tries to > address your concerns, but being mindful of not reading badly regardless > of the flag values: OK, please apply. Thanks for redoing. By the way: please fix your patch mailing system not to ever send in format=flowed again. I had to apply all your redone patches manually. :-/ Cheers, Ralf > from Gary V. Vaughan <[EMAIL PROTECTED]> > * libtoolize.m4sh: Copying just libtool.m4 for hand maintained > aclocal.m4 doesn't work. List all required files in that case, > using the files from installed libltdl if available. Also, list > the additional files required when using libltdl. > Reported by Patrick Welche <[EMAIL PROTECTED]>.
