Hi,
I received the bug report below when compiling GNU FreeDink on
Debian/kFreeBSD and Debian/Hurd.
It seems that there's an issue with install-reloc:
https://buildd.debian.org/status/fetch.php?pkg=freedinkarch=kfreebsd-amd64ver=1.08.20120427-1stamp=1335561117
A code block was very strangely indented, without apparent reason,
since 2009-09-09.
2012-05-01 Bruno Haible br...@clisp.org
getcwd: Fix misindentation.
* m4/getcwd.m4 (gl_FUNC_GETCWD_NULL): Fix indentation.
--- m4/getcwd.m4.orig Tue May 1 17:10:44 2012
+++ m4/getcwd.m4
Dmitriy Selyutin wrote:
I've found an interesting piece of code:
# This code helps migrating from --import to --add-import or --update. It
can
# be removed on 2012-01-01.
if test $mode = import test $# = 0; then
echo gnulib-tool: cowardly refusing to erase the module list. 12
Hi,
Wnen I compile some gnulib modules for a glibc systems in cross-compilation
mode (by specifing both --host and --build at configure time, with a different
value), I'm seeing results such as
checking for putenv compatible with GNU and SVID... no
whereas for the hosted build I get
retitle 671044 freedink: FTBFS[!linux]: too many args to install-reloc
tags 671044 + patch
thanks
Hi Sylvain,
On 01/05/12 15:56, Sylvain wrote:
It seems that there's an issue with install-reloc:
Yes there is, but what is its purpose anyway? For Linux builds it is
not used so maybe it
1) Cross-compilation guesses, that is, the third branch of AC_RUN_IFELSE,
should better be marked as guessing no, rather than no, for clarity.
This fixes most occurrences. Exempt are those that come from Autoconf
(to be addressed later).
Here's the proposed patch. Objections?
Hi Steven,
'install-reloc' indeed does nothing special in the case of
FreeDink+Linux, but it is run as part of the gnulib infrastructure.
(I see you understand the relocatable-prog module quite well, but I
post this link for other people to understand how it works:)
Hi,
On 01/05/12 21:13, Sylvain wrote:
(I see you understand the relocatable-prog module quite well, but I
post this link for other people to understand how it works:)
http://www.gnu.org/software/gnulib/manual/html_node/Supporting-Relocation.html#Supporting-Relocation
Ummm, not really, not
Configure output when cross-compiling:
checking for working chown... no
This message comes from AC_FUNC_CHOWN in Autoconf. Here's a proposed patch
that touches Gnulib only. Should I submit a patch for Autoconf? Or is
Autoconf always preferring pessimistic guesses, regardless of platform?
On 05/01/2012 02:03 PM, Bruno Haible wrote:
Should I submit a patch for Autoconf? Or is
Autoconf always preferring pessimistic guesses, regardless of platform?
I would think that a patch would be welcome for Autoconf,
just as it is for gnulib -- we like to support GNU systems
well.
On 05/01/2012 02:48 PM, Bruno Haible wrote:
2) On glibc systems, which are often used as cross-compilation targets
(think of embedded systems (routers, map navigation devices, etc.)),
the cross-compilation guesses should better be correct. I.e. when
no problem is known on
When cross-compiling, configure says:
checking for working getgroups... no
Here's a proposed patch for improving this in gnulib. Again, would it be
better to modify AC_FUNC_GETGROUPS in Autoconf?
2012-05-01 Bruno Haible br...@clisp.org
getgroups: Avoid guessing no when
Configure outputs when cross-compiling:
checking for GNU libc compatible malloc... no
checking for GNU libc compatible realloc... no
Here's a proposed patch for improving the guess for glibc targets.
Again, the question is whether to modify the macro in Autoconf proper.
2012-05-01 Bruno
On 05/01/2012 03:41 PM, Bruno Haible wrote:
Configure outputs when cross-compiling:
checking for GNU libc compatible malloc... no
checking for GNU libc compatible realloc... no
Here's a proposed patch for improving the guess for glibc targets.
Again, the question is whether to modify
When cross-compiling, configure also reports wrongly:
checking whether lstat correctly handles trailing slash... no
Here is a proposed patch. Jim, OK to apply?
2012-05-01 Bruno Haible br...@clisp.org
lstat: Avoid guessing no when cross-compiling to glibc systems.
*
When cross-compiling, I also see this wrong guess:
checking whether gettimeofday clobbers localtime buffer... yes
This proposed patch should improve it. OK to apply, Jim Paul?
2012-05-01 Bruno Haible br...@clisp.org
gettimeofday: Avoid bad guess when cross-compiling to glibc
When cross-compiling, canonicalize.m4 also guesses wrong:
checking whether realpath works... guessing no
This should fix it. Objections?
2012-05-01 Bruno Haible br...@clisp.org
canonicalize[-lgpl]: Avoid guessing no when cross-compiling to glibc.
* m4/canonicalize.m4
When cross-compiling, I also see:
checking whether strerror(0) succeeds... guessing no
For glibc platforms, this can be improved. Objections, Eric?
2012-05-01 Bruno Haible br...@clisp.org
strerror: Avoid guessing no when cross-compiling to glibc systems.
* m4/strerror.m4
On 05/01/2012 04:17 PM, Bruno Haible wrote:
When cross-compiling, I also see:
checking whether strerror(0) succeeds... guessing no
For glibc platforms, this can be improved. Objections, Eric?
I'm pretty sure that glibc has always worked with strerror(0). I know
we had glibc problems
When cross-compiling, I also see this wrong guess:
checking for signbit macro... guessing no
This should fix it. (Most of this patch is merely reindentation.)
2012-05-01 Bruno Haible br...@clisp.org
signbit: Avoid guessing no when cross-compiling to glibc systems.
*
On 2012-04-29 09:56:03 -0700, Paul Eggert wrote:
On 04/29/2012 08:34 AM, Vincent Lefevre wrote:
I don't like the fact that you assume by default that compilers
are non-conforming
Nor do I. How about the following improvement to the heuristic?
It is just a heuristic so we can't do a perfect
On 2012-04-29 18:28:03 +0200, Bruno Haible wrote:
And clashes regarding the 'noreturn' macro? I don't see any. In a compilation
unit, the last definition matters, and since both definitions (from gnulib
and from the other package) are supposedly correct, what is the problem?
If stdnoreturn.h
On 05/01/2012 06:11 PM, Vincent Lefevre wrote:
On 2012-04-29 18:28:03 +0200, Bruno Haible wrote:
And clashes regarding the 'noreturn' macro? I don't see any. In a compilation
unit, the last definition matters, and since both definitions (from gnulib
and from the other package) are supposedly
On 05/01/2012 03:04 PM, Bruno Haible wrote:
012-05-01 Bruno Haiblebr...@clisp.org
gettimeofday: Avoid bad guess when cross-compiling to glibc systems.
* m4/gettimeofday.m4 (gl_FUNC_GETTIMEOFDAY_CLOBBER): Require
AC_CANONICAL_HOST. When cross-compiling, guess no on glibc
Steven Chamberlain wrote:
It seems that there's an issue with install-reloc:
Yes there is, but what is its purpose anyway?
install-reloc is used when --enable-relocatable is used. The purpose of
this option is to give the installer the ability to install binaries at
any location in the file
Hi Sylvain,
I received the bug report below when compiling GNU FreeDink on
Debian/kFreeBSD and Debian/Hurd.
It seems that there's an issue with install-reloc:
https://buildd.debian.org/status/fetch.php?pkg=freedinkarch=kfreebsd-amd64ver=1.08.20120427-1stamp=1335561117
On 2012-05-01 18:17:12 -0600, Eric Blake wrote:
On 05/01/2012 06:11 PM, Vincent Lefevre wrote:
If stdnoreturn.h (either the standard one or from Gnulib) is used
together with GCC's
__attribute__ ((noreturn))
in the other package, things will not work as expected.
That would be
Hi Eric,
Sorry for the delays,
Le 25 avr. 2012 à 19:36, Eric Blake a écrit :
On 04/07/2012 05:48 AM, Akim Demaille wrote:
Hi!
I would like bison to used gnulib's build-aux/po/Makefile.in.in,
but I don't understand how I am supposed to do that. bison's
bootstrap is sync'ed with that of
28 matches
Mail list logo
