Bug#619845: [PATCH] tagdemo: Link to libfoo
Hi Kurt, * Kurt Roeckx wrote on Sat, Apr 02, 2011 at 09:06:05PM CEST: * tests/tagdemo/Makefile.am: Link to all libraries that the demo application uses. Thanks, I'm pushing that patch in your name. Cheers, Ralf 2011-04-10 Kurt Roeckx ... tagdemo: do not rely on picking up symbols from indirect deps. * tests/tagdemo/Makefile.am: Link to all libraries that the demo application uses. diff --git a/tests/tagdemo/Makefile.am b/tests/tagdemo/Makefile.am index e945c25..295e7b6 100644 --- a/tests/tagdemo/Makefile.am +++ b/tests/tagdemo/Makefile.am @@ -1,6 +1,6 @@ ## Makefile.am -- Process this file with automake to produce Makefile.in ## -## Copyright (C) 2003, 2004, 2005 Free Software Foundation +## Copyright (C) 2003, 2004, 2005, 2011 Free Software Foundation ## Written by Gary V. Vaughan, 2003 ## ## This file is part of GNU Libtool. @@ -47,7 +47,7 @@ noinst_HEADERS = foo.h baz.h conv.h bin_PROGRAMS = tagdemo tagdemo_SOURCES = main.cpp -tagdemo_LDADD = libbaz.la +tagdemo_LDADD = libbaz.la libfoo.la libtool: $(LIBTOOL_DEPS) $(SHELL) ./config.status --recheck -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619845: test suite failures with --no-copy-dt-needed-entries
Hi Kurt, * Kurt Roeckx wrote on Mon, Mar 28, 2011 at 01:08:22AM CEST: We're seeing this currently in Debian: FAIL: tests/tagdemo-make.test /bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -o tagdemo main.o libbaz.la -ldl libtool: link: g++ -g -O2 -o .libs/tagdemo main.o ./.libs/libbaz.so -ldl -Wl,-rpath -Wl,/home/kurt/libtool/libtool-2.4/_inst-tagdemo/lib /usr/bin/ld: main.o: undefined reference to symbol 'convenience' /usr/bin/ld: note: 'convenience' is defined in DSO //home/kurt/libtool/libtool-2.4/tests/tagdemo/.libs/libfoo.so.0 so try adding it to the linker command line //home/kurt/libtool/libtool-2.4/tests/tagdemo/.libs/libfoo.so.0: could not read symbols: Invalid operation collect2: ld returned 1 exit status I was expecting this to break with the change in toolchain. In case you wonder why we get that error now, it's because gcc now passes --no-copy-dt-needed-entries to the linker. I think I've mailed the lists with a similar case just like this before. The problem is main.o is linking to libbaz (which is not a convenience library, and is linked to libfoo), but is using symbols from libfoo directly and not linking too it. This is just wrong, but used to work because ld fixed it for you. And libtool probably also tries to fix it for you if you don't set link_all_deplibs to no. I plan to adjust all the tests to add the proper libraries. Would you be interested in the patch? Yes, please. I'm not quite sure whether the test case was intended to exercise this, or it was just inadvertent; the latter is more likely. Presumably one or more of the tests from the Autotest testsuite in Libtool fail as well due to this? Thanks for the report, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570719: rep-gtk and librep-dev bash/dash libtool breakage
* Tim Retout wrote on Thu, Oct 14, 2010 at 09:36:07AM CEST: I almost just closed #570723 - but I'll reassign to libtool, because maybe it should 'set -e' or something (unless that's not portable). Issues such as this: | eval: 1: libtool_args+=: not found | eval: 1: libtool_args+=: not found typically come from configure running the tests under a different shell than libtool. This is often because the configure.ac messes with $SHELL and/or $CONFIG_SHELL, or CONFIG_SHELL is set in the environment. The build log referenced looks like it ran under bash: | checking whether the shell understands some XSI constructs... yes | checking whether the shell understands +=... yes yet make uses /usr/lib/rep/x86_64-pc-kfreebsd-gnu/libtool which doesn't seem to have been created by configure. I suspect that /usr/lib/rep/x86_64-pc-kfreebsd-gnu/libtool assumes /bin/sh is bash, because at the time and on the system it was created it was bash. In all likelihood, this is not a Libtool bug. Cheers, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592892: openmpi: FTBFS: Compilation errors
clone 592892 -1
reassign -1 autoconf
retitle -1 AS_VAR_GET regression
tags -1 + upstream
thanks
[ http://bugs.debian.org/592892 ]
If I got above right, then I'm cloning this bug for Autoconf and
marking it as upstream bug; adding bug-autoconf in Cc:.
* Sebastian Andrzej Siewior wrote on Wed, Aug 18, 2010 at 04:53:44PM CEST:
config/f77_get_alignment.m4.
The value should be set in third last line
| $2=AS_VAR_GET([type_var])
It was transformed earlier into
| ofc_type_alignment=$ompi_cv_f77_alignment_LOGICALp1
but become something totally differnt,
|ofc_type_alignment=`eval 'as_val=${'type_var'};$as_echo $as_val'`
After carefully replacing it with AS_VAR_COPY we get
| eval ofc_type_alignment=\$$as_type_var
which does the job for now. Puh. Now out quick!
Well, AS_VAR_GET is (intentionally) undocumented, so your use of
AS_VAR_COPY is the right thing to do (which is why I'll leave the
original bug for openmpi). Still, this is a regression in upstream
Autoconf that I think should be fixed. The issue is that '*' needs to
be translated to 'p' here and the string treated as literal here:
cat configure.ac \EOF
AC_DEFUN([OMPI_F77_GET_ALIGNMENT],[
AS_VAR_PUSHDEF([type_var], [ompi_cv_f77_alignment_$1])
$2=AS_VAR_GET([type_var])
AS_VAR_POPDEF([type_var])dnl
])
AC_INIT
OMPI_F77_GET_ALIGNMENT([LOGICAL*1], [result])
EOF
autoconf
tail configure
should contain a line like:
result=$ompi_cv_f77_alignment_LOGICALp1
but instead has something like:
as_type_var=`$as_echo ompi_cv_f77_alignment_LOGICAL*1 | $as_tr_sh`
result=`eval 'as_val=${'type_var'};$as_echo $as_val'`
Thanks,
Ralf
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592711: libtool create a FTBS on imagemagick on HPPA (due to bash ?)
* Bastien ROUCARIES wrote on Thu, Aug 12, 2010 at 10:48:37AM CEST: FTBS with (http://tinyurl.com/2b5bbqo) [...] /bin/bash ./libtool --mode=install /usr/bin/install -c filters/analyze.la '/build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4/debian/tmp/usr/lib/ImageMagick-6.6.0/modules-Q16/filters' libtool: install: warning: relinking `filters/analyze.la' libtool: install: (cd /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4; /bin/bash /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4/libtool --silent --tag CC --mode=relink gcc -std=gnu99 -std=gnu99 -I/usr/include/lqr-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fopenmp -g -O2 -Wall -W -pthread -no-undefined -export-symbols-regex .* -shared -module -avoid-version -L/usr/lib/X11 -o filters/analyze.la -rpath /usr/lib/ImageMagick-6.6.0/modules-Q16/filters filters/filters_analyze_la-analyze.lo magick/libMagickCore.la -lm -inst-prefix-dir /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4/debian/tmp) malloc: ../bash/parse.y:4620: assertion botched malloc: block on free list clobbered Aborting/libtool: line 964: 30018 Aborted An assertion is a bug in bash_4.1-3 rather than in libtool; but possibly libtool is doing something on line 964 or before that which bash dislikes and which it could avoid doing. Please run the failing relink command with --debug added as first argument to libtool, --silent removed, and attach the output, that might provide additional clues. That command would be: cd /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4 /bin/bash /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4/libtool --debug --tag CC --mode=relink gcc -std=gnu99 -std=gnu99 -I/usr/include/lqr-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fopenmp -g -O2 -Wall -W -pthread -no-undefined -export-symbols-regex .* -shared -module -avoid-version -L/usr/lib/X11 -o filters/analyze.la -rpath /usr/lib/ImageMagick-6.6.0/modules-Q16/filters filters/filters_analyze_la-analyze.lo magick/libMagickCore.la -lm -inst-prefix-dir /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4/debian/tmp Also, which /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4/libtool --version ? Lastly, can you post the output of sed -n 940,980p /build/buildd-imagemagick_6.6.0.4-2.2-hppa-WKfFIA/imagemagick-6.6.0.4/libtool please? Thanks, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557632: broken test for mmap
tags upstream patch
thanks
Hello Michal,
thanks for the bug report. Adding autoconf-patches.
* Michal Čihař wrote on Mon, Nov 23, 2009 at 01:27:43PM CET:
the mmap test currently present in autoconf fails to compile:
conftest.cpp:154: warning: deprecated conversion from string constant to
'char*'
conftest.cpp:157: error: invalid conversion from 'void*' to 'char*'
what leads to not detecting mmap on Debian and because of this some
packages fail to build (I did hit this on sdcv).
Proposed patch. Fixes the test with CC=g++. OK to apply and add Michal
to THANKS?
Cheers,
Ralf
Fix AC_FUNC_MMAP regression with C++ compiler in 2.65.
* lib/autoconf/functions.m4 (AC_FUNC_MMAP): Use const char*
for the constant string. Cast void* to char* for assignment.
* NEWS, THANKS: Update.
Report by Michal Čihař.
diff --git a/NEWS b/NEWS
index b72eb17..32fa957 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,10 @@
GNU Autoconf NEWS - User visible changes.
+* Major changes in Autoconf 2.65a (-??-??) [experimental]
+ Released by
+
+** AC_FUNC_MMAP works in C++ mode again. Regression introduced in 2.64.
+
* Major changes in Autoconf 2.65 (2009-11-21) [stable]
Released by Eric Blake, based on git versions 2.64.*.
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 6b6e7fc..14a8cb9 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1258,6 +1258,7 @@ int
main ()
{
char *data, *data2, *data3;
+ const char *cdata2;
int i, pagesize;
int fd, fd2;
@@ -1282,10 +1283,10 @@ main ()
fd2 = open (conftest.txt, O_RDWR | O_CREAT | O_TRUNC, 0600);
if (fd2 0)
return 4;
- data2 = ;
- if (write (fd2, data2, 1) != 1)
+ cdata2 = ;
+ if (write (fd2, cdata2, 1) != 1)
return 5;
- data2 = mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2, 0L);
+ data2 = (char *) mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2,
0L);
if (data2 == MAP_FAILED)
return 6;
for (i = 0; i pagesize; ++i)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523031: Bug#523030: wrong quoting in aclocal's python.m4 check
Hello Matthias,
* Matthias Klose wrote on Tue, Apr 14, 2009 at 09:13:24AM CEST:
'${prefix}' and '${exec_prefix}' are passed unexpanded to get_python_lib()),
and
the macro then defaults to the hardcoded alternative case. The patch passes
the
real path names to get_python_lib(), and only for the case, where the prefix
argument was specified on the command line (the case for a missing prefix
argument is handled inside the get_python_lib() function).
tested the macro with python versions 2.0 up to trunk, and the 3.0 and 3.1
branches.
Thanks for the bug report and patch. The way I read info Automake
Python, the non-expanded '${prefix}' and '${exec_prefix}' were done
on purpose. Now, I'm not a python expert, nor have I worked much with
the Automake support code for python (except for accepting a patch into
the git tree that adds python 3.0 support). Can you describe or provide
an example that is fixed with your patch and broken without, and look
over the above-mentioned section in the manual, to see whether it still
describes the situation accurately with your patch?
Thanks,
Ralf
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494112: File::Copy::move truncates open file when rename fails (was: sshfs silently truncates files...)
* Niko Tyni wrote on Fri, Aug 08, 2008 at 10:23:28AM CEST: Frankly, I don't think File::Copy is doing anything wrong. Agreed. I'll reassign this to autoconf unless convinced otherwise. Just applying the $out-close patch from Ralf found in this bug log should fix it. Yes. Please reassign and mark as fixed-upstream. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494112: File::Copy::move truncates open file when rename fails (was: sshfs silently truncates files...)
* Vincent Lefevre wrote on Fri, Aug 08, 2008 at 11:01:49AM CEST: On 2008-08-08 11:23:28 +0300, Niko Tyni wrote: The documentation specifically says move() will copy the file if rename() fails, and IMO it's clearly the responsibility of the caller to make sure the file is closed or at least flushed. Well, this is not obvious. Even without using lsof, if Perl has a mapping between filenames and file handles in its own internal structures, this could be done. Perhaps it should be documented (e.g. in NOTES) that the caller must close the file or flush it when it is copied, in particular via move. But really this isn't a limitation of the perl module, but of the underlying file system and/or operating system. I guess on w32 the move will outright fail if the file is open. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494112: File::Copy::move truncates open file when rename fails (was: sshfs silently truncates files...)
* Vincent Lefevre wrote on Thu, Aug 07, 2008 at 03:38:21PM CEST:
On 2008-08-07 14:26:07 +0200, Vincent Lefevre wrote:
The size of the truncated file appears here. If I understand correctly,
the failed rename has truncated the configure.tmp file.
It wasn't truncated, but copied without being flushed first.
The problem comes from:
if ($atomic_replace !rename($output.tmp, $output)) {
move (${output}.tmp, $output)
or fatal cannot rename ${output}.tmp as $output: $!;
}
in /usr/bin/autom4te. File::Copy::move tries to do a rename first.
FWIW, upstream Autoconf has this fix:
commit 1ee48b2c8b2b83482fccd773df08cdac66cce493
Author: Slava Sysoltsev [EMAIL PROTECTED]
Date: Wed Apr 9 10:46:08 2008 -0600
Flush buffered output before exit.
* bin/autom4te.in (handle_output): Explicitly close file.
* THANKS: Update.
See http://lists.gnu.org/archive/html/autoconf/2008-04/msg00026.html.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474162: libtool: FAIL: demo-exec.test on mips/mipsel
Hi Kurt, * Kurt Roeckx wrote on Sat, Apr 05, 2008 at 03:21:24PM CEST: On Thu, Apr 03, 2008 at 09:55:23PM +0200, Kurt Roeckx wrote: The testsuite fails on mips/mipsel with the following error: PASS: demo-make.test FAIL: demo-exec.test PASS: depdemo-nofast.test [...] 1 of 111 tests failed This is most likely a problem in the toolchain since we switched to gcc-4.3. I currently can't look closer at it since there isn't any mips/mipsel development machine available. VERBOSE=yes output for the failing test and the two before that would be helpful in any case when there is a system available again, whether it is a GCC or a Libtool bug. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464157: libtool incorrectly parses command-line options
* David Paleino wrote on Tue, Feb 05, 2008 at 04:05:59PM CET: http://pastebin.com/f54c9f170 http://pastebin.com/f4501fd89 This very much looks like a version mismatch between the ltmain.sh and the libtool.m4 (and other macro) files. Maybe you used 1.5.x libtoolize? Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464157: libtool incorrectly parses command-line options
* David Paleino wrote on Tue, Feb 05, 2008 at 04:38:17PM CET: Il giorno Tue, 5 Feb 2008 16:34:43 +0100 Ralf Wildenhues [EMAIL PROTECTED] ha scritto: * David Paleino wrote on Tue, Feb 05, 2008 at 04:05:59PM CET: http://pastebin.com/f54c9f170 http://pastebin.com/f4501fd89 This very much looks like a version mismatch between the ltmain.sh and the libtool.m4 (and other macro) files. Maybe you used 1.5.x libtoolize? Well, I don't think. Can you please *check* rather than think? Thank you. Look at the version of the ltmain.sh file used, post ./libtool --version and ./libtool --config libtoolize comes with the package libtool itself, and I just had installed the experimental version. Thus, libtoolize must have been updated as well, together with libtool. Right? Yes. And you reran libtoolize, and aclocal with the right flags to find and reran autoconf and configure? Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464157: libtool incorrectly parses command-line options
* David Paleino wrote on Tue, Feb 05, 2008 at 08:32:21PM CET: $ libtool --version ltmain.sh (GNU libtool 1.2525 2007/10/16 22:45:48) 2.1a This is irrelevant. $ ./libtool --version ltmain.sh (GNU libtool) 1.5.24 Debian 1.5.24-1ubuntu1 (1.1220.2.456 2007/06/24 02:25:32) This is the bug. The ltmain.sh file used came from 1.5.24 not from 2.1a. ./libtool --config: http://pastebin.com/f47ec56a This is from 2.1a. libtool --config: http://pastebin.com/f4ffad97b Again, this is irrelevant. libtoolize comes with the package libtool itself, and I just had installed the experimental version. Thus, libtoolize must have been updated as well, together with libtool. Right? Yes. And you reran libtoolize, and aclocal with the right flags to find and reran autoconf and configure? Erm... no. I feared to change upstream's source code, which would result in different md5sums at the end. And yes, I know upstream shouldn't include any generated code, but many do. :( The point is, whether you re-bootstrap or not, you must use matching versions of the macro files (*.m4) and the script file (ltmain.sh). Your breakage comes from not doing that. I don't recall how to mark a Debian bug as invalid/fixed. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464157: libtool incorrectly parses command-line options
tags wontfix thanks * David Paleino wrote on Tue, Feb 05, 2008 at 10:07:17PM CET: Il giorno Tue, 5 Feb 2008 20:50:01 +0100 Ralf Wildenhues [EMAIL PROTECTED] ha scritto: ... I don't recall how to mark a Debian bug as invalid/fixed. Tag it as wontfix? Done. Thanks, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462021: marked as done (autoconf: autconf must depend on automaken, not just recommend it)
Hello Ben, * Debian Bug Tracking System wrote on Tue, Jan 22, 2008 at 06:18:10AM CET: Binary: autoconf Architecture: source all Version: 2.61-5 Distribution: unstable Urgency: low [...] * debian/control: Depend on automake | automaken, instead of just recommending automaken, because the autoreconf program actually invokes binaries from automake. Thanks to Norman Ramsey [EMAIL PROTECTED] for reporting this bug. Closes: #462021. Are you going to depend on (some version of) libtool and gettext, too? autoreconf may invoke libtoolize and autopoint as well. FWIW, I don't think this is the right way to go. If autoreconf invokes aclocal or automake, that means the package being autoreconf'ed depends on automake, not autoconf. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395466: AM_PATH_CHECK causes possibly undefined macro errors
[ http://bugs.debian.org/395466 ]
Hello Josh,
* Josh Triplett wrote on Fri, Oct 27, 2006 at 09:33:30AM CEST:
--- check.m4.orig 2006-10-13 12:24:41.0 -0700
+++ check.m4 2006-10-26 23:55:54.0 -0700
@@ -4,8 +4,9 @@
AC_DEFUN([AM_PATH_CHECK],
[
- AC_MSG_WARN([[AM_PATH_CHECK() is deprecated]])
- AC_MSG_WARN([[use PKG_CHECK_MODULES([CHECK], [check = 0.9.4]) instead]])
+ empty=
+ AC_MSG_WARN([A${empty}M_PATH_CHECK() is deprecated])
+ AC_MSG_WARN([[use P${empty}KG_CHECK_MODULES([CHECK], [check = 0.9.4])
instead]])
AC_ARG_WITH([check],
[ --with-check=PATH prefix where check is installed [default=auto]])
Yuck three times. 1. Learn to use Quadrigraphs:
AC_MSG_WARN([[AM@[EMAIL PROTECTED]() is deprecated]])
http://www.gnu.org/software/autoconf/manual/html_node/Quadrigraphs.html
2. Double quotation [[ ]] does successfully prevent expansion of macros,
iff all macros calling this one have been quoted correctly, i.e., once.
3. m4_pattern_forbid was invented to forbid some patterns. User macros
should simply not begin with 'AM_'. That prefix is reserved for
Automake, and also used by a set of legacy macros from some other
packages. When you invent new names, use a different prefix, like
'jt_', or, for pkg-config, 'PKG_'. I reckon that the damage is already
done with AM_PATH_CHECK though. Which is the name of the package that
defines it? It is broken, the bug should be moved to this package, and
to fix it, the package should add something like
m4_pattern_allow([^AM_PATH_CHECK$])
to its macro.
Hope that helps.
Cheers,
Ralf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373953: ruby1.9: FTBFS: Error in ext/bigdecimal Makefile
Hello, * Steinar H. Gunderson wrote on Sun, Jun 25, 2006 at 02:11:12PM CEST: On Fri, Jun 16, 2006 at 01:03:43PM -0400, Daniel Schepler wrote: Does the line 143 contain |#_!!_#|? Yes, it does: .cc.|#_!!_#|o: For those interested in squashing this bug, it looks like some problem in the autoconf interaction. Yes. ruby1.9 seems to subscribe to the non-recommended practice of automatically running autoconf at build time, Moving away from this practice isn't going to fix this failure though -- see below. and at some point, either autoconf got buggy, or something changed; Yes. Autoconf changed the internal representation of its substitution when it started to support newlines in substitutions (and thus needed to employ some quoting _inside_ the config.status script). the part about '|#_!!_#|' originates from the configure script in AC_OUTPUT; it's supposed to be sed-ed out at some point, but for some reason, this doesn't happen. It does happen for all files which are created with AC_CONFIG_FILES, which, in this case, is only the toplevel Makefile. AFAICS, a simple solution would simply to be turning off the running of autoconf at build time, run autoconf from some older version and then simply include that in the diff. Nope. That simply won't fix things, because Autoconf will not back out this new feature. The problem is in the mkconfig.rb script in the toplevel directory of ruby1.9-1.9.0+20060423: it tries to parse config.status and thus extract the values of some substitutions. This is extremely brittle, and fails as shown. I can assure you it will also fail again in the future, and it will fail with older Autoconf versions for some of the values extracted. The point is that the contents of config.status are *really* internal details, undocumented, and not in any way guaranteed to be stable. Neither is the order or some overrides of substitutions. (For example, a future Autoconf version may employ awk to do the substitutions, in which case the syntax will change greatly.) If you want to know the values of substituted variables, then simply use a substituted file to extract them portably: add AC_CONFIG_FILES([values.rb]) to configure.in, and create a file values.rb.in with [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ ... As I don't know ruby syntax really, you will have to take care of the proper quoting yourself. And possibly some more changes, I don't quite understand the mkconfig.rb script. If you have any more questions to be able to fix this, don't hesitate to ask; I'd be happy to help with the Autoconf related things. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372179: AC_CANONICAL_SYSTEM overwrites $@
Hello Justin, Tollef, everyone, * Justin Erenkrantz wrote on Fri, Jun 16, 2006 at 09:12:11PM CEST: The point of our autoconf macro is to allow 'shortcuts', such that the argument --with-layout=Foo rewrites prefix/libexec/etc to a specific set of values (dictated by our file config.layout) and then have explicit passed parameters override those 'layout' files. Yes. But I think you would agree that having your own parsing routine that is almost a complete copy of the Autoconf one is not a common, usual way of using Autoconf, and that it's not encouraged by the Autoconf documentation to override the settings this way, nor do your own argument parsing at all. Right? The common way to do argument parsing with Autoconf is to use AC_ARG_WITH and AC_ARG_ENABLE. (Note I'm not arguing the usefulness of doing so for your needs; in fact, I understand that you do this. But if you want to be able to rely on Autoconf upgrades to not break your setup, you should push for changes to Autoconf itself so it provides enough interfaces so you don't need to do your own parsing. It's just not natural to do so.) It looks like you switched the docs to recomend using AC_ARG_ENABLE, but I'm not sure how that would address our issue. Paul pointed out that $@ won't stay constant througout the configure script. In fact, this has never been guaranteed. Apr was just lucky enough not to have been hit by it, and Autoconf wasn't careful enough to document that there is no such guarantee. (Although strictly speaking, one may argue that since the Autoconf manual doesn't give such a guarantee, you should not assume it.) Paul now fixed the documentation to state this non-guarantee more prominently (the mention of AC_ARG_ENABLE is just a hint at the macros to use instead). Let me repeat what I wrote in an earlier message in this bug report[1]: The AC_CHECK_PROG macro (for example) has overwritten the positional parameters _for years_, at least since Autoconf-2.13. From a pure Autoconf view, and I'm exaggerating here on purpose, relying on $@ to remain constant over the course of the configure script is akin to relying on undefined behavior in C. Now we all know there is a world of difference between a well-defined language such as C, and a mostly not so well defined language such as Autoconf-on-top-of-portable-Shell. But to speak of a major unexpected change as has been done in this bug report seems a bit exaggerated to me. I would even find a NEWS entry for this change in AC_CANONICAL_SYSTEM to be more than necessary. We might be able to delay the AC_CANONICAL_SYSTEM invocation until after we process the layout options - but I seem to recall a reason why we delayed invoking those macros. As as decent workaround, you could just save the positional parameters early after AC_INIT and restore them when you need them; good code to this end has already been posted in this bug report as well, see [2]. I see absolutely no need for Autoconf to do more for this bug. * Tollef Fog Heen [EMAIL PROTECTED] wrote: | [...] putting some kind | of Debian-specific patch that saves and restores the positional | parameters (if indeed there's a way to do that) around | AC_CANONICAL_SYSTEM. Apart from the «ewww» factor, why can't it do its work in a subshell and echo back the parameters to be set and those get eval-ed by configure? Because configure scripts are slow enough as they are; a subshell is a noticeable slowdown when done several times. Because avoiding echoing avoids the unportabilites of echo. Doing away with modifing $@ in general is needlessly limiting us to not be able to make efficient use of the only array variable that is available in Shell programming.[3] I hope this clears things up enough. Cheers, Ralf [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372179 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372179#msg49 [3] Eventually, Autoconf will make use of shell functions. At that time you will have no chance to have $@ survive the first shell function invocation portably (some older shells do not restore $@ after a function returns; I'm not sure whether they will be of concern any more then or not). So really the guarantee Paul gave in the message above is probably even stronger than we can give.
Bug#372179: AC_CANONICAL_SYSTEM overwrites $@
Hello Justin, Tollef, * Justin Erenkrantz wrote on Sun, Jun 18, 2006 at 11:40:12PM CEST: On 6/18/06, Tollef Fog Heen [EMAIL PROTECTED] wrote: Currently, if configure is passed --sbindir=, it just overrides $sbindir without flagging that at all. If it, in addition to changing $sbindir, it'd set ac_param_sbindir either to 1 to show that sbindir is derviced from a command line argument or to the value passed on the command line. If we had this, APR_LAYOUT could check if ac_param_sbindir was set, and if so skip setting sbindir from the layout. Would this be an acceptable solution for both the APR and the autoconf people? That could work for our purposes, yes. It'd be cleaner to boot, too. So what do you do with --bindir=/foo --with-layout=bar --sbindir=/baz shouldn't the bar layout override bindir but not sbindir? (Note I don't know the exact semantics --with-layout is supposed to have.) BTW, all of the apr_common.m4 code and your .in files anyway need an audit pass to cope with the GCS-induced changes for --datarootdir and its consequences; see the Autoconf NEWS entries and the manual about the changed default directories (and new ones). Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372241: Bug#372179: marked as done (autoconf: AC_CANONICAL_SYSTEM overwrites $@)
Hi Stepan, * Stepan Kasal wrote on Thu, Jun 15, 2006 at 06:12:51PM CEST: [...] several macros in Autoconf overwrite the positional parameters, not just AC_CANONICAL_SYSTEM. For example, AC_CHECK_PROG does, so do some others. [...] I agree that we should document this limitation. I would document that any Autoconf macro can change the positional parameters. See here: http://lists.gnu.org/archive/html/autoconf-patches/2006-06/msg00065.html There is only one question: should we make the commitment that AC_INIT leaves the parameters untached or not? (I don't know the answer.) Above change has implicitly made this assumption. I think it is ok; we should allow ourselves to change this only when we give the user a better, documented method to access them (remember that we agreed a couple of weeks ago not to do this documenting now?). Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372241: Bug#372179: marked as done (autoconf: AC_CANONICAL_SYSTEM overwrites $@)
Getting bug-autoconf into play: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372241 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372179 Date: Thu, 8 Jun 2006 20:09:30 +0200 From: Julien Danjou [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: apr-util: FTBFS: cannot stat `./debian/tmp/usr/include/apr-1.0': No such file or directory Package: apr-util Version: 1.2.7-1 Severity: serious There was a problem while autobuilding your package: dh_install -a cp: cannot stat `./debian/tmp/usr/include/apr-1.0': No such file or directory dh_install: command returned error code 256 make: *** [binary-arch] Error 1 This is because the APR_PARSE_ARGUMENTS macro of apr-util parses the configure arguments, very similar to what _AC_INIT_PARSE_ARGS does; and AC_CANONICAL_SYSTEM now overwrites the positional parameters by using set x ... I could find an online copy of APR_PARSE_ARGUMENTS here: http://apache.hpi.uni-potsdam.de/document/sources/httpd-2.0.45-html/source/build/apr_common.m4 A note to the apr people: several macros in Autoconf overwrite the positional parameters, not just AC_CANONICAL_SYSTEM. For example, AC_CHECK_PROG does, so do some others. There is really no guarantee that $@ is conserved throughout the configure script. IMHO the best would be to just document this limitation in the Autoconf manual. This would mean, however, that apr needs to rewrite its macros. It may be possible to reorder macro invocations so the expansion of APR_PARSE_ARGUMENTS comes before any AC_CANONICAL_*? Thoughts? Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353346: libtool_1.9+20051221-1(hppa/experimental): FTBFS: segv in test
Hi Frank,
* Frank Lichtenheld wrote on Fri, Feb 17, 2006 at 05:19:37PM CET:
Package: libtool
Version: 1.9+20051221-1
Severity: serious
This looks like the test suite failed, but not like the source failed to
build. Is a successful `make check' prerequisite for a successful
build? If yes: is the gcj compiler broken on hppa or did I simply mess
up with the very little java foo I have (look at tests/convenience.at,
search for Java convenience archives)?
Snipped the log to relevant parts.
Cheers,
Ralf (please keep in mind I have no way to test this particular
package, me no DD)
your package in experimental failed to build from source on hppa:
| Automatic build of libtool_1.9+20051221-1 on meitner by sbuild/hppa 79
| Build started at 20060217-1539
|
**
| ** Using build dependencies supplied by package:
| Build-Depends: debhelper (= 4.0), texi2html, texinfo, file, g77 |
fortran77-compiler, gfortran | fortran95-compiler, gcj [!mips !mipsel
!netbsd-i386 !hurd-i386 !kfreebsd-i386], automake1.9, autoconf,
autotools-dev, dpatch
[...]
| convenience.at:265: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS
--main=foo$i -o main foo$i.lo liba$conv.la
| stderr:
| stdout:
| libtool: link: gcj -g -O2 --main=foo2 -o .libs/main .libs/foo2.o
./.libs/liba12.so -Wl,-rpath -Wl,/notexist
| libtool: link: creating main
| convenience.at:266: ./main_static; lt_status=$?; if test $lt_status -eq 0;
then :;
|elif test X$host != X$build \
| { test -x ./main_static || test -x ./main_static$EXEEXT; }
|then (exit 77); else (exit $lt_status); fi
| convenience.at:267: ./main; lt_status=$?; if test $lt_status -eq 0; then :;
|elif test X$host != X$build \
| { test -x ./main || test -x ./main$EXEEXT; }
|then (exit 77); else (exit $lt_status); fi
| --- /dev/null 2006-02-09 03:10:09.0 +
| +++ /build/buildd/libtool-1.9+20051221/tests/testsuite.dir/at-stderr
2006-02-17 15:27:21.0 +
| @@ -0,0 +1 @@
| +/build/buildd/libtool-1.9+20051221/tests/testsuite: line 3182: 8292
Segmentation fault ./main
| convenience.at:267: exit code was 139, expected 0
| 12. convenience.at:219: 12. Java convenience archives (convenience.at:219):
FAILED (convenience.at:267)
*big snip*
| | configure:21063: checking for gcj
| | configure:21079: found /usr/bin/gcj
| | configure:21089: result: gcj
| | configure:21182: checking if gcj supports -fno-rtti -fno-exceptions
| | configure:21217: result: no
| | configure:21234: checking for gcj option to produce PIC
| | configure:21467: result: -fPIC
| | configure:21476: checking if gcj PIC flag -fPIC works
| | configure:21494: gcj -c -Wall -g -O2 -fPIC conftest.java 5
| | configure:21498: $? = 0
| | configure:21511: result: yes
| | configure:21532: checking if gcj static flag -static works
| | configure:21560: result: no
| | configure:21572: checking if gcj supports -c -o file.o
| | configure:21593: gcj -c -Wall -g -O2 -o out/conftest2.o conftest.java 5
| | configure:21597: $? = 0
| | configure:21619: result: yes
| | configure:21624: checking if gcj supports -c -o file.o
| | configure:21671: result: yes
| | configure:21701: checking whether the gcj linker (/usr/bin/ld) supports
shared libraries
| | configure:22757: result: yes
| | configure:22890: checking dynamic linker characteristics
| | configure:23509: result: GNU/Linux ld.so
| | configure:23553: checking how to hardcode library paths into programs
| | configure:23578: result: immediate
*big snip*
| make: *** [build-stamp] Error 1
|
**
| Build finished at 20060217-1702
| FAILED [dpkg-buildpackage died]
Full build log(s):
http://experimental.ftbfs.de/build.php?ver=1.9+20051221-1pkg=libtoolarch=hppa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
