e the brain wanted to type with but the fingers did not comply.
> +for a week and produce a directory that takes more than 100 GB, maybe even 1
> TB,
> +of disk space.)
>
> @item Transfer gnulib directory
>
--
Tim RiceMultitalents
t...@multitalents.net
ersal time (a.k.a. GMT), __TZ should be set to
> + (timezone_t) 0.
> +
--
Tim RiceMultitalents
t...@multitalents.net
macros
> macOS: self-contained
> mingw: self-contained
> Minix: self-contained
> musl: self-contained
> NetBSD: self-contained
> OpenBSD: self-contained
> Solaris 10: #include -> #include ,
> #include , defines only macros
> Solaris 11: #includ
/opt/csw/include' 'CXX=/opt/csw/bin/g++-5.5' 'CXXFLAGS=-O2
> > -pipe -fno-omit-frame-pointer -m64 -march=opteron'
>
> Autotools is broken on Solaris here. It has been broken for years.
Autotools have worked fine for me on Solaris for many years but I
discovered early to put -m64 in
I could come up with at the time.
--
Tim RiceMultitalents
t...@multitalents.net
Hi Bruno,
On Sun, 11 Oct 2020, Bruno Haible wrote:
> Tim Rice wrote:
> > ./gnulib-tool --create-testdir --dir=/var/tmp --with-tests \
> > --single-configure --avoid=havelib-tests fseterr freadable fwritable \
> > fbufmode freading fwriting freadptr freadseek fre
need to bump its serial number.
Sorry, I've seen enough patches come by on this list, I should have
remembered that.
> * It does not make the code clearer to remove the HAVE___FLBF and
> HAVE___FPURGE
> tests in fbufmode.c and fpurge.c.
Fine with me.
Thank
On Wed, 7 Oct 2020, Bruno Haible wrote:
> I hope the main conclusions from the table [1] stand?
Yes.
> Bruno
>
> [1] https://lists.gnu.org/archive/html/bug-gnulib/2020-10/msg00022.html
>
--
Tim RiceMultitalents
t...@multitalents.net
age says that both __USLC__ and
> __SCO_VERSION__ are defined. Which contradicts what Tim Rice just found
> out, namely that *none* of the 6 compilers that he tested defines both
> __USLC__ and __SCO_VERSION__.
Actually the table *does* show __USLC__ and __SCO_VERSION__ defined
in the native compiler for bot
uire bringing libc more up to date.
If/when that happens, [gs]etprogname() would be in there.
--
Tim RiceMultitalents
t...@multitalents.net
| || | | | |
> __sysv5__ | || | 1 | | 1 |
> +-++-+---+-+---+
>
> Bruno
>
> [1]
> https://opensource.apple.com/sou
Hi Bruno,
On Sat, 3 Oct 2020, Bruno Haible wrote:
> Tim Rice wrote:
> > > +# elif defined __SCO_VERSION__ /* SCO OpenServer/UnixWare */
> >
> > While __SCO_VERSION__ covers Openserver 6 and UnixWare 7,
> > what is normally used for 6 and 7 is __U
I have attached an additional patch for the stdio parts
2020-09-30 Tim Rice
* lib/stdio-impl.h: Add support for UnixWare
* lib/freadahead.c: Use __fpending on UnixWare
* lib/fflush.c: Update comments for UnixWare
* lib/fpending.c: Likewise.
* lib
_ /* SCO OpenServer/UnixWare */
While __SCO_VERSION__ covers Openserver 6 and UnixWare 7,
what is normally used for 6 and 7 is __USLC__ for the native compiler
and __sysv5__ for gcc
Ie.
# elif defined __USLC__ || defined __sysv5__
--
Tim RiceMultitalents
t...@multitalents.net
On line 24 of lib/fwriting.c we see
/* This file is not used on systems that have the __fwritable function,
Should that not be __fwriting instead of __fwritable ?
--
Tim RiceMultitalents
t...@multitalents.net
On Thu, 24 Sep 2020, Tim Rice wrote:
>
> Hi Bruno,
>
> On Fri, 25 Sep 2020, Bruno Haible wrote:
>
> > Tim Rice wrote:
> > > I've attached a patch to address the fact that UnixWare does not have
> > > stdio_ext.h but has some __X() stdio helper f
Hi Paul,
On Thu, 24 Sep 2020, Paul Eggert wrote:
> On 9/24/20 1:49 PM, Tim Rice wrote:
> > Wrap "#include " in HAVE_STDIO_EXT_H insead of HAVE___X
>
> Shouldn't this also add AC_CHECK_HEADERS_ONCE([stdio_ext.h]) to the
> corresponding .m4 files, as fpending.m4 and g
Hi Bruno,
On Fri, 25 Sep 2020, Bruno Haible wrote:
> Tim Rice wrote:
> > I've attached a patch to address the fact that UnixWare does not have
> > stdio_ext.h but has some __X() stdio helper functions.
>
> In which header file are they declared? Can you show these d
Never mind, I can't read today.
On Thu, 24 Sep 2020, Tim Rice wrote:
>
> This does not look right.
> ---
> 57#elif defined _IOERR/* AIX, HP-UX, IRIX, OSF/1,
> Solaris, OpenServer, mingw, MSVC, NonStop Kernel, OpenVMS */
> 58# if defined WINDOW
flbf, lines 68 and 69 cover that.
--
Tim RiceMultitalents
t...@multitalents.net
I've attached a patch to address the fact that UnixWare does not have
stdio_ext.h but has some __X() stdio helper functions.
Wrap "#include " in HAVE_STDIO_EXT_H insead of HAVE___X
--
Tim RiceMultitalents
t...@multitalents.net
diff --git a/ChangeLog b
[reviving an old thread that started here
https://lists.gnu.org/archive/html/bug-gnulib/2020-02/msg00025.html]
Hi Bruno,
On Thu, 6 Feb 2020, Tim Rice wrote:
> On Wed, 5 Feb 2020, Bruno Haible wrote:
>
> } Hi Tim,
> }
> } > > > I discoverd a n
dules/utimens-tests
modules/fdutimensat-tests
modules/utimensat-tests
modules/fchownat-tests
modules/stat-time-tests
} The right form should be doc/Copyright/request-assign.future (in the gnulib
} repository).
Filled out and e-mailed in.
}
} Bruno
}
--
Tim RiceMultitalents
t...@multitalents.net
find the right assignent papers and who to send
them to.
>
> Bruno
>
>
--
Tim RiceMultitalents
t...@multitalents.net
://uw714doc.xinuos.com/en/man/html.3C/nap.3C.html
What would be the prefered replacement name? gnulib_nap?
How do I find out if I have filled out copyright assignment papers
for the gnulib project?
Thanks.
--
Tim RiceMultitalents
t...@multitalents.net
Hi Bruno,
/tmp/df-nm.gz /tmp/df-truss.gz
On Mon, 15 Oct 2018, Bruno Haible wrote:
{ Tim Rice wrote:
{ > Xinuos's latest release
{ > (last month) of the SCO OpenServer 5 product uses the SVR3.2 kernel also.
{
{ Can you determine which system calls the vendor 'df' program uses?
{ T
hat Xinuos's latest release
(last month) of the SCO OpenServer 5 product uses the SVR3.2 kernel also.
--
Tim RiceMultitalents
t...@multitalents.net
Hi Paul,
On Wed, 26 Apr 2017, Paul Eggert wrote:
> Tim Rice wrote:
> > Sad to hear gnulib doesn't care about C89. UnixWare (a currently shipping
> > product) has a C89 compiler.
>
> That should be OK as UnixWare's supplier also supports GCC, and recommends GCC
>
uch is life with long lived products.
> With that in mind, I propose (and have installed) the attached patch to try to
> document the current situation more accurately. Comments and further patches
> are welcome.
>
--
Tim RiceMultitalents
t...@multitalents.net
for ANSI C header files
[snip]
--
Tim RiceMultitalents
t...@multitalents.net
a few more bugs in Version JM 93u 2011-02-08
(Finally UnixWare has a good ksh)
Bruno
--
Tim RiceMultitalents(707) 887-1469
t...@multitalents.net (707) 456-1146
On Thu, 1 Nov 2007, Bruno Haible wrote:
Tim Rice wrote:
None of that, but I did find a problem with the build environment
...
I got the build environment fixed now.
OK. But this means I cannot trust your 6 other reports either. If you want
something to be done about them, you need
On Tue, 30 Oct 2007, Bruno Haible wrote:
Tim Rice wrote:
The build fails on Caldera OpenLinux 3.1.1
Here is a snipet of the build log
make all-am
make[2]: Entering directory `/usr/local/src/gnu/m4-1.3.10/lib'
source='/opt/src/gnu/m4-1.4.10/lib/gl_array_list.c'
object
snippet4.c: In function `main':
snippet4.c:15: parse error before `)'
Bruno
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
/../lib -g -O2 -c
/opt/src/gnu/m4-1.4.10/tests/test-vasprintf-posix.c
gcc: Internal compiler error: program cpp got fatal signal 11
make[4]: *** [test-vasprintf-posix.o] Error 1
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
35 matches
Mail list logo
