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 glibc systems or Linu
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
On 2012-05-01 18:17:12 -0600, Eric Blake wrote:
> On 05/01/2012 06:11 PM, Vincent Lefevre wrote:
> > If (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 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=freedink&arch=kfreebsd-amd64&ver=1.08.20120427-1&stamp=1335561117
> https://build
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 fi
On 05/01/2012 03:04 PM, Bruno Haible wrote:
012-05-01 Bruno Haible
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 platforms.
Lo
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 suppos
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 (either the
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
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
signbit: Avoid "guessing no" when cross-compiling to glibc systems.
* m4/signbit.m4 (gl_SI
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:
checking whether strerror(0) succeeds... guessing no
For glibc platforms, this can be improved. Objections, Eric?
2012-05-01 Bruno Haible
strerror: Avoid "guessing no" when cross-compiling to glibc systems.
* m4/strerror.m4 (gl_FUNC_STRERR
When cross-compiling, canonicalize.m4 also guesses wrong:
checking whether realpath works... guessing no
This should fix it. Objections?
2012-05-01 Bruno Haible
canonicalize[-lgpl]: Avoid "guessing no" when cross-compiling to glibc.
* m4/canonicalize.m4 (gl_FUNC_REALPATH_W
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
gettimeofday: Avoid bad guess when cross-compiling to glibc systems.
*
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
lstat: Avoid "guessing no" when cross-compiling to glibc systems.
* m4/lstat.m4 (gl_FUNC_
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 m
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 Ha
On 05/01/2012 03:21 PM, Bruno Haible wrote:
> 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?
Patches for existing autoconf macros to ma
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
getgroups: Avoid "guessing no" when cross-compiling to glibc
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 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.
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?
2012
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 b
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:)
http://www.gnu.org/software/gn
> 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?
201
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 shouldn'
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
checkin
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 li
A code block was very strangely indented, without apparent reason,
since 2009-09-09.
2012-05-01 Bruno Haible
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.m4Tue May 1
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=freedink&arch=kfreebsd-amd64&ver=1.08.20120427-1&stamp=1335561117
https://buildd.debian.org/status/
30 matches
Mail list logo
