Thanks for looking into this.
+[AC_REQUIRE([AC_CANONICAL_HOST])
Is there some way we can do this without requiring AC_CANONICAL_HOST?
We're close to a release for Autoconf, and requiring this at the last
minute for AC_SYS_LARGEFILE is a bit of a stretch.
That is, instead of AS_CASE([$host_os
On 4/15/23 15:27, Paul Eggert wrote:
My suggestion is that we give up on having dependencies address this
particular issue, since they cause more trouble than they cure. Let's
just go back to year2038 not depending on anything other than
largefile, and tell people to include config.h first wi
I wrote:
> > Also, maybe it is necessary to distinguish the use of these two Autoconf
> > macros without and with Gnulib?
> >- Without Gnulib, they could both fail on MSVC.
> >- But with Gnulib, they should both succeed on MSVC.
but I was wrong regarding the expected outcome. The correct e
An Android app has a UI written in Java, not on top of a C/C++ based GUI
toolkit (GNOME, Qt, KDE, wxWidgets, ...). Gnulib cannot help you porting this
part of an application to Android.
But when an application has a large part written in C, and you want to reuse
this part in the Android app, Gnuli
On 4/15/23 05:22, Bruno Haible wrote:
it is the 'year2038' module which,
in packages that don't follow the "include first" rule,
will cause trouble.
The year2038 module by itself does not cause the trouble: the trouble is
caused by a combination of things. One could just as ea
On FreeBSD 13.0 and newer, a testdir of all of gnulib fails to compile:
c++ -ferror-limit=0 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -I.
-I../../gltests -I.. -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I.
-I../../gltests -I.. -I../../gltests/.. -I../gllib -I../../gltests/../gllib
-
While I know that the module 'year2038-required' is being worked on by Paul
[1], it hampers my ability to do portability testing if the testdirs that
contain all of gnulib fail to configure on a third of the possible platforms.
For now, I need to exclude module 'year2038-required' from these testdi
Paul Eggert wrote:
> This patch doesn't look right, since it causes year2038 to depend on a
> bunch of modules like sys_shm that most programs don't need.
>
> I don't know why year2038 should depend on sys_shm etc.
year2038 makes arrangements to turn 'time_t' into a 64-bit type. There can
be con
One of these patches had a bug (found by the continuous integration):
On Debian 9, a testdir fails to compile:
In file included from selinux-at.h:17:0,
from selinux-at.c:21:
./selinux/selinux.h:23:5: error: #if with no expression
#if
^
Makefile:9945: recipe for t
