On 07/17/2018 09:05 PM, Barath Aron wrote:
Thanks, I'll let you know about my findings.
As a start, I got all the headers from a NetBSD 4.0 with gcc installed.
After looking into those headers, I noticed the following:
a) There is no getfsstat(), but there is getvfsstat(), and its argument
i
* m4/hard-locale.m4: Remove.
* modules/hard-locale (Files): Remove m4/hard-locale.m4.
(configure.ac): Do not call gl_HARD_LOCALE.
---
ChangeLog | 5 +
NEWS| 2 ++
m4/hard-locale.m4 | 11 ---
modules/hard-locale | 2 --
4 files changed, 7 insertions(+), 13
* gnulib-tool (func_import): Break actioncmd log line
into multiple lines.
---
ChangeLog | 6 +
gnulib-tool | 87 -
2 files changed, 52 insertions(+), 41 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ecb9e48..05b0544 10064
On Thu, 5 Jul 2018, Paul Eggert wrote:
> Although Gnulib hasn't needed a difftime module yet, it might need one once
> this 32- vs 64-bit time_t stuff lands into glibc, so let's keep difftime.c
> usable for Gnulib.
I don't think we should make such requests of contributers for code that
is not s
On 07/17/2018 08:49 PM, Paul Eggert wrote:
Barath Aron wrote:
Does gnulib support BSD's getmntinfo()? Since it looks not, what can
we do?
Gnulib ports to the operating systems (including BSD operating
systems) available at the time Gnulib was written, and it still ports
to the current versio
Barath Aron wrote:
Does gnulib support BSD's getmntinfo()? Since it looks not, what can we do?
Gnulib ports to the operating systems (including BSD operating systems)
available at the time Gnulib was written, and it still ports to the current
versions of these operating systems as far as we k
I don't want to flood the mailing lists, so let me merge Bruno's mail again.
On 07/17/2018 05:49 PM, Paul Eggert wrote:
On 07/16/2018 10:41 PM, Barath Aron wrote:
I guess it is more like a hack than a solution.
Quite true. We need a real solution here, not a hack. But that will
need someone
Barath Aron wrote:
> ... on an OS that partially (mostly?) supports POSIX, and
> implements widely used BSD functions. And when I saw the getfsstat() and
> now the getmntinfo() functions I put them into the libc
If you want to minimize porting efforts in the long run, I would
suggest to implemen
On 07/16/2018 10:41 PM, Barath Aron wrote:
I guess it is more like a hack than a solution.
Quite true. We need a real solution here, not a hack. But that will need
someone to look into it. If Threos is supposed to be like POSIX, it
should use the POSIXish part of the relevant Gnulib code, not
On Tue, 2018-07-17 at 10:29 +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 17, 2018 at 10:14:18AM +0200, Andrea Bolognani wrote:
> > It looks like gnulib commit 2afc250c6fae changed the ffs()
> > detection code, and now when compiling with MinGW I get HAVE_FFS=1
> > instead of HAVE_FFS=0 and the fa
On Tue, Jul 17, 2018 at 10:14:18AM +0200, Andrea Bolognani wrote:
> On Sat, 2018-07-14 at 09:20 +0200, Michal Privoznik wrote:
> > The changelog is quite long because we haven't updated gnulib in
> > a while. Anyway, among the new changes you'll find GCC 8 support,
> > faster build time, mingw fixe
On Sat, 2018-07-14 at 09:20 +0200, Michal Privoznik wrote:
> The changelog is quite long because we haven't updated gnulib in
> a while. Anyway, among the new changes you'll find GCC 8 support,
> faster build time, mingw fixes and many others.
Ironically, this makes building on MinGW *worse* :)
L
12 matches
Mail list logo
