Ørjan Malde wrote:
> > If on Linux, the result is 'guessing no (mishandles large arguments)',
> > it should be the same on systems that emulate the Linux system calls. Right?
> >
>
> No, we have handled the mishandling of large arguments and nanosleep passes
> all of gnulib's tests unlike linux.
On Tuesday, February 6th, 2024 at 12:47 AM, Bruno Haible
wrote:
> Hi,
>
> Ørjan Malde wrote:
>
> > from running the testsuite:
> > PASS: test-nanosleep
> > PASS: test-ftruncate.sh
> > PASS: test-utime
> > PASS: test-utimens
> > PASS: test-utimensat
> > PASS: test-rename
>
>
> OK...
>
> > @@
Hi,
Ørjan Malde wrote:
> from running the testsuite:
> PASS: test-nanosleep
> PASS: test-ftruncate.sh
> PASS: test-utime
> PASS: test-utimens
> PASS: test-utimensat
> PASS: test-rename
OK...
> @@ -119,6 +119,9 @@ AC_DEFUN([gl_FUNC_NANOSLEEP],
> # Guess it halfway works when the kern
from running the testsuite:
PASS: test-nanosleep
PASS: test-ftruncate.sh
PASS: test-utime
PASS: test-utimens
PASS: test-utimensat
PASS: test-rename
hopefully this time my contribution is less noisy. :-)
Regards,
Ørjan
>From 3feffaa8b70de4b8bf1491006a871bda63ca31f2 Mon Sep 17 00:00:00 2001
From:
Ørjan Malde wrote:
> Yes, although there is one exception which is realpath,
> as the midipix framework provides a syscall and realpath wrapper that
> overrides musl's which does behave correctly.
But you haven't extended the test to include the test code that is
currently '#ifdef __linux__'. You'
Ørjan Malde wrote:
> the runtime components contain extra checks to align the behavior
> with linux's.
So, this justifies this patch (according to your statement that these
test programs work).
2023-02-17 Bruno Haible
Improve cross-compilation for midipix.
Reported by Ørjan M
--- Original Message ---
On Friday, February 17th, 2023 at 4:31 PM, Bruno Haible wrote:
> Ørjan Malde wrote:
>
> > > So, will config.sub stay as it is, and the pattern to check for is
> > > midipix* ?
> >
> > The triplet naming is out of my control, it's integrated with tools new
> >
Ørjan Malde wrote:
> > So, will config.sub stay as it is, and the pattern to check for is midipix*
> > ?
> >
>
> The triplet naming is out of my control, it's integrated with tools new
> and existing, and personally I like it the way it is.
OK, then the pattern is midipix*.
I'm committing th
y another libc could be
> > ported
> > but I don't see that happening.
>
>
> OK, so it will be correct to use the musl cross-compilation guesses for
> non-system-call related things also for midipix.
>
Yes, although there is one exception which is realpath,
as
Ørjan Malde wrote:
> I had no intention of hiding my name:-)
OK, we're past step 1 :)
> we rely on musl for the C library, theoretically another libc could be ported
> but I don't see that happening.
OK, so it will be correct to use the musl cross-compilation guesses for
non-
]
> > and the lack of 'psxscl' in [4]. And if it's work-in-progress, the
> > configure results will certainly change until the first release.
>
>
> While yes, it's still work-in-progress it's already usable enough
> to be a daily driver unix-like environm
gure results will certainly change until the first release.
>
While yes, it's still work-in-progress it's already usable enough
to be a daily driver unix-like environment on windows
the kernel derived cross-guesses I've added will most definitely
not change, we try to follow linux
se.
It seems safer, instead, to treat 'midipix*' like 'musl*' everywhere.
Not only in the cross-compilation guesses but also in m4/musl.m4,
m4/pthread_rwlock_rdlock.m4, m4/setlocale_null.m4 and so on. Do you
agree?
Bruno
[1] https://midipix.org/
[2] https://github.com/mid
* m4/calloc.m4: When cross-compiling, use the
result from native compilation.
* m4/canonicalize.m4: Likewise.
* m4/cbrtl.m4: Likewise.
* m4/ceil.m4: Likewise.
* m4/ceilf.m4: Likewise.
* m4/ceill.m4: Likewise.
* m4/chmod.m4: Likewise.
* m4/d-ino.m4: Likewise.
* m4/exp2l.m4: Likewise.
* m4/expm1.m4:
gure.
The results in setlocale_null.m4 were determined by initially setting them
to 'yes' and seeing which of the test programs fail. test-setlocale_null-mt-all
failed, whereas test-setlocale_null-mt-one succeeded.
2021-02-07 Bruno Haible
Add cross-compilation guesses for Midni
/m4/gnulib-common.m4
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 44
+# gnulib-common.m4 serial 45
dnl Copyright (C) 2007-2019 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -115,6 +115,33
Now that it's clear that glibc bug
<https://sourceware.org/bugzilla/show_bug.cgi?id=13701> will never be fixed,
it's time to update the corresponding cross-compilation guess in gnulib.
2019-08-29 Bruno Haible
lock: Fix cross-compilation guesses.
* m4/pthread_
When a configure test's result is merely a guess, not a determined fact,
it's a good practice to flag it as a guess in the 'configure' output.
Let's do so in a couple of more places.
2019-03-23 Bruno Haible
Clarify that cross-compilation guesses are guess
In a testdir build for Android 4.3, REPLACE_MKFIFO gets set to 1. Later there
is a declaration conflict regarding rpl_mkfifo.
Better avoid this trouble by adjusting the cross-compilation guesses for POSIX
functions that are usually implemented as system calls on Linux.
2018-05-13 Bruno Haible
Hi,
I'm adding cross-compilation guesses for native Windows, so that cross-
compilation to e.g. mingw using the Debian cross packages should now work
properly.
For reference, the way I produced this change is as follows:
1) Determine list of files:
rm -f `find . -name '*~&
Jim Meyering wrote:
> This looks fine, modulo a nit in the comment above:
> s/works on when/works when/
Oops, right. Fix applied.
Bruno
Bruno Haible wrote:
> Another suboptimal cross-compilation guess is
>
> checking for working nanosleep... cross-compiling
>
> This test has 3 possible results:
> - "yes", it works, no override needed.
> - "no (mishandles large arguments)", means it works halfway, the
> override in lib/nan
Bruno Haible wrote:
> Another suboptimal cross-compilation guess is
>
> checking whether tzset clobbers localtime buffer... yes
>
> This fixes it.
>
>
> 2012-05-05 Bruno Haible
>
> tzset: Avoid guessing wrong when cross-compiling to glibc systems.
> * m4/tzset.m4 (gl_FUNC_TZSET_CLO
Bruno Haible wrote:
> This cross-compilation guess is also suboptimal:
>
> checking for d_ino member in directory struct... no
>
> since d_ino is known to work on glibc/Linux since ever:
> glibc/sysdeps/unix/sysv/linux/bits/dirent.h is essentially unchanged since
> 1997.
>
>
> 2012-05-05 Bruno H
Another suboptimal cross-compilation guess is
checking for working nanosleep... cross-compiling
This test has 3 possible results:
- "yes", it works, no override needed.
- "no (mishandles large arguments)", means it works halfway, the
override in lib/nanosleep.c can use the system's nano
Another suboptimal cross-compilation guess is
checking whether link(2) dereferences a symlink... unknown
The only known platforms which show
checking whether link(2) dereferences a symlink... yes
are MacOS X, FreeBSD, NetBSD, OpenBSD, Minix, AIX, HP-UX, OSF/1.
Whereas on Linux and Cygwin syst
Another suboptimal cross-compilation guess is
checking whether tzset clobbers localtime buffer... yes
This fixes it.
2012-05-05 Bruno Haible
tzset: Avoid guessing wrong when cross-compiling to glibc systems.
* m4/tzset.m4 (gl_FUNC_TZSET_CLOBBER): Require AC_CANONICAL_HOST.
This cross-compilation guess is also suboptimal:
checking for d_ino member in directory struct... no
since d_ino is known to work on glibc/Linux since ever:
glibc/sysdeps/unix/sysv/linux/bits/dirent.h is essentially unchanged since
1997.
2012-05-05 Bruno Haible
d-ino: Avoid guessi
I'm seeing this wrong guess on a glibc system:
checking whether ungetc works on arbitrary bytes... guessing no
2012-05-05 Bruno Haible
fseeko-tests, ftello-tests: Avoid "guessing no" when cross-compiling.
* m4/ungetc.m4 (gl_FUNC_UNGETC_WORKS): Require AC_CANONICAL_HOST. Whe
> 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.)
There is another wrong guess in the same file:
checking for signbit compiler built-ins... guessing no
This combined patch
Eric Blake wrote:
> I'm pretty sure that glibc has always worked with strerror(0).
Yes. I've checked my build logs collection and find no indication of
a problem on a glibc platform.
Regarding strerror, there is also the suboptimal cross-compilation guess:
checking for working strerror functio
> 2012-05-01 Bruno Haible
>
> lstat: Avoid "guessing no" when cross-compiling to glibc systems.
> * m4/lstat.m4 (gl_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK): When cross-
> compiling, set gl_cv_func_lstat_dereferences_slashed_symlink to
> "guessing yes" or "guessing no".
>
Eric Blake wrote:
> Can we add other known-good systems, like Cygwin? But that can be an
> incremental improvement in a later patch.
OK, done in the patch for Autoconf. The patch for gnulib is simpler now:
2012-05-03 Bruno Haible
*alloc-gnu, eealloc: Avoid "guessing no" when cross-c
Eric Blake wrote:
> Patches for existing autoconf macros to make smarter guesses would be
> welcome, in my mind.
Thanks for applying the patch so quickly. It simplifies the logic of the
change in gnulib:
2012-05-03 Bruno Haible
getgroups: Avoid "guessing no" when cross-compiling to g
Paul Eggert wrote:
> I would think that a patch would be welcome for Autoconf,
> just as it is for gnulib -- we like to support GNU systems
> well.
Thanks for the advice. Now that the patch has been accepted in Autoconf,
it's more straightforward to override AC_FUNC_CHOWN in Autoconf < 2.70.
I'm a
Bruno Haible wrote:
> Jim Meyering wrote:
>> However, I would find the above code easier to read if it were
>> written on fewer lines:
>>
>> case "$host_os" in
>> *-gnu*) $1 ;; # Guess yes on glibc systems.
>> *) $2 ;; # If we don't know, assume the worst.
>> esac
>
> Will
Jim Meyering wrote:
> with this:
>
> case "$gl_cv_func_getgroups_works" in
> *yes) ;;
> *) REPLACE_GETGROUPS=1 ;;
> esac
OK, I'll do like this.
Bruno
Jim Meyering wrote:
> However, I would find the above code easier to read if it were
> written on fewer lines:
>
> case "$host_os" in
> *-gnu*) $1 ;; # Guess yes on glibc systems.
> *) $2 ;; # If we don't know, assume the worst.
> esac
Will it also work if $1 or $2 contai
ble
>
> getgroups: Avoid "guessing no" when cross-compiling to glibc systems.
> * m4/getgroups.m4 (gl_FUNC_GETGROUPS): When cross-compiling, set
> ac_cv_func_getgroups_works without invoking AC_FUNC_GETGROUPS.
To apply that, I had to first apply your other one
Sub
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 the macro in Autocon
Bruno Haible wrote:
> 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.
Hi Jim,
> I find it more concise/readable than the above:
>
> if { case "$gl_cv_func_rmdir_works:$gl_cv_func_unlink_works" in
> *yes:*yes) false;;
> *) true;;
>esac
> }; then
OK, I'm taking this way of writing the conditional.
Thanks for your feedback. I will co
Bruno Haible wrote:
> 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-compili
Bruno Haible wrote:
> When cross-compiling, canonicalize.m4 also guesses wrong:
>
> checking whether realpath works... guessing no
>
> This should fix it. Objections?
This looks fine. Thanks.
> 2012-05-01 Bruno Haible
>
> canonicalize[-lgpl]: Avoid "guessing no" when cross-compiling t
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 k
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
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
>>
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
> 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
I get
checking for putenv compatible with GNU and SVID... yes
Likewise for some other functions (malloc, realloc, utimes, dup2, getgroups,
...).
Two things are wrong here:
1) Cross-compilation guesses, that is, the third branch of AC_RUN_IFELSE,
should better be marked as "guessing no",
On 08/28/2010 07:08 AM, Bruno Haible wrote:
2010-08-28 Bruno Haible
AC_FUNC_STRNLEN: more realistic cross-compilation guess
* lib/autoconf/functions.m4 (AC_FUNC_STRNLEN): Require
AC_CANONICAL_HOST. When cross-compiling, guess it works everywhere
except on AIX.
ic cross compilation guess, too?
Autoconf has traditionally used a pessimistic approach to cross compilation
guesses. If the AC_FUNC_STRNLEN macro in Autoconf was to use a more precise
cross compilation guess, there would indeed be no need to duplicate this code
in gnulib. Here i
63 matches
Mail list logo
