Bruno Haible wrote:
But Gnulib is a *source-code* library. No one compiles Gnulib binaries
separately from the application binaries.
I build it as a Gnulib.DLL. I know, not supported, but
it can be done. Much better for me in how I use it
in e.g. Wget, etc.
--
--gv
Paul Eggert wrote:
On 12/30/21 07:48, Gisle Vanem wrote:
-#elif defined HAVE_TIMESPEC_GETRES
+#elif defined HAVE_TIMESPEC_GETRES && HAVE_TIMESPEC_GETRES
This change has an effect only if there's the equivalent of '#define HAVE_TIMESPEC_GETRES 0' somewhere.
Since &#
Trying the new test 'test-timespec_getres.exe'
gave me a "Stack overflow - code c0fd (first chance)"
since in my case here on Windows/MSVC, the function really is:
long int gettime_res (void)
{
struct rpl_timespec res;
timespec_getres (&res, 1);
and then 'timespec_getres()' calls
Jan Nieuwenhuizen wrote:
Do you see a cheap way to return the correct casing for the rest of the
file name? That could be nice, maybe a change like that has a chance of
being accepted.
The only safe way I've found is to call
'GetShortPathName()' and 'GetLongPathNameA()'
to get the true correc
Bruno Haible wrote:
I added this __try/__catch uses because
- POSIX wants an error return rather than a program crash for
calls like close(-1).
- We make extensive use of such calls in the test suite.
If you find, by extensive testing, that SANE_LIBRARY_HANDLING works
for your progra
I've been trying to speed-up a 'diff -r dir1 dir2'
by disabling the "no-throw" stuff for MSVC/clang-cl:
MSVC_INVALID_PARAMETER_HANDLING == SANE_LIBRARY_HANDLING
(suspecting it imposes some overhead. Maybe MSVC's
__try/__catch has lower overhead?)
But building with 'SANE_LIBRARY_HANDLING' crash
Bruno Haible wrote:
The 'e' modifier to fopen() has the effect of adding an
O_CLOEXEC to the underlying open() call.
BY preprocessing 'fopen.c', I see the 'rpl_fopen()'
in my case is rather short. Since 'GNULIB_FOPEN_GNU'
seems *not* to be defined, it passes mode to
'orig_fopen()' with "re" in
I have an issue with GNU-diff which uses
this Gnulib function 'add_exclude_file()'.
A command like:
diff -X exclude new old > x.diff
or
diff --exclude-from=exclude new old > x.diff
Adding some trace in 'diff.c', I see that 'add_exclude_file()'
returns -1 and 'errno = 22' (EINVAL).
But this
Bruno Haible wrote:
For lib/getprogname.c we would need the approval of
Pino Toscano
Paul Eggert
Jim Meyering
Gisle Vanem
Daniel Richard G
John David Anglin
Benji Wiebe
No problem. Go ahead.
Hello list.
Trying to compile 'argmatch.c' with '-DTEST', I
got this error:
argmatch.c(269): error C2172: 'argmatch_to_argument':
actual parameter is not a pointer: parameter 1
It should be patched to:
--- a/lib/argmatch.c 2021-01-01 14:12:49
+++ b/lib/argmatch.c 2021-03-18 09:48:46
@@ -26
Bruno Haible wrote:
The 'immutable' module, so far, worked only on platforms with mmap() and
mprotect(). With this patch, it also works on native Windows.
...
+ if (!CloseHandle (h))
+{
+ UnmapViewOfFile (mem_w);
+ UnmapViewOfFile (mem_r);
+ CloseHandle (h);
+ return
On Windows/MSVC, I get an abort() on line 85:
ASSERT (((uintptr_t) aligned16_blocks[i] % 16) == 0);
m4/malloc-align.m4 indicates that MALLOC_ALIGN should
be 8 or 16. But all (?) Windows targets do have the
'_aligned_malloc()' [1] function which is found nowhere.
So patching like this, test-al
Bruno Haible wrote:
clang on Windows, by default, does not link with '-loldnames' (like mingw and
MSVC 14 do).
You mean when using 'lld-link'?
One can use 'link.exe' with 'clang-cl' with no problem.
And is IMHO better than clang's linker. Why assume what
linker *must* be used?
Bruno Haible wrote:
When building a testdir of all of gnulib with clang 9 on a glibc system,
I see these compilation errors:
Good work on the clang support, but it looks like you have not
tried clang-cl with the Microsoft 'Windows-Kit' headers.
Microsoft added support for 'clang/clang-cl' in
Bruno Haible wrote:
2020-08-03 Bruno Haible
integer_length: Optimize for MSVC.
* lib/integer_length.c: Include .
(integer_length): With MSVC, use the _BitScanReverse built-in.
With clang-cl I get link-results like:
integer_length_l.obj : error LNK2005: _integer_len
Paul Eggert wrote:
-extern void dfawarn (const char *);
+extern _Noreturn void dfawarn (const char *);
That can't be right, as dfawarn typically does return.
Does the following work around the compiler bug? If not we can use stronger
medicine.
diff --git a/tests/test-dfa-match-aux.c b/tests
Thanks Paul for a fast patch. 10 minutes!
Here's an error though:
test-dfa-match-aux.c
test-dfa-match-aux.c(39): error C2381: 'dfawarn': redefinition;
'__declspec(noreturn)' or '[[noreturn]]' differs
lib\dfa.h(125): note: see declaration of 'dfawarn'
which I fixed by:
--- a/lib/dfa.h 2
Just a warning from 'cl', but that should be
removed IMHO:
argz.h(58): warning C4138: '*/' found outside of comment (compiling source
file argz.c)
argz.h(69): warning C4138: '*/' found outside of comment (compiling source
file argz.c)
Because of argz.h:
extern size_t argz_count (const cha
The lines in count-one-bits.h:
# pragma intrinsic __cpuid
# pragma intrinsic __popcnt
# pragma intrinsic __popcnt64
triggers these warnings:
count-one-bits.h(79): warning C4083: expected '('; found identifier '__cpuid'
count-one-bits.h(80): warning C4083: expected '('; found identifier '
The use of '__argv' as parameter names, causes this
error from clang-cl:
argz.c(234,1): error: conflicting types for 'argz_extract'
argz_extract (const char *argz, size_t len, char **argv)
^
.\argz.h(68,13): note: previous declaration is here
extern void argz_extract (const char *restric
Bruno Haible wrote:
I have a situation with clang's 'lld-link' linker
in Wget2 where the symbol 'crc32()' in Gnulib is called
instead of the correct symbol 'crc32()' in Zlib.
Are you sure the symbol that is called comes from gnulib?
The only references to 'crc32' in gnulib are in the module 'c
I have a situation with clang's 'lld-link' linker
in Wget2 where the symbol 'crc32()' in Gnulib is called
instead of the correct symbol 'crc32()' in Zlib.
In Zlib's inflate.c:
#ifdef GUNZIP
if ((state->wrap & 2) && hold == 0x8b1f) { /* gzip header */
state->check = crc32(0L, Z_NU
In https://lists.gnu.org/archive/html/bug-gnulib/2019-12/msg00050.html
Bruno Haible did this:
diff --git a/lib/locale.in.h b/lib/locale.in.h
index 918d4dd..77b8b3b 100644
--- a/lib/locale.in.h
+++ b/lib/locale.in.h
@@ -64,6 +64,18 @@
# define LC_MESSAGES 1729
#endif
+#if defined _MSC_VER
+# de
I see the Pthread stuff was changed massively lately.
Now the function 'glwthread_spin_trylock()' called from
pthread-spin.c is now-where to be found.
An omission?
--
--gv
Bruno Haible wrote:
On native Windows with MSVC, I observe this test failure:
FAIL: test-getaddrinfo
==
FAIL test-getaddrinfo.exe (exit status: 4)
The cause is a missing call to WSAStartup(). This patch fixes it.
I found the same problem with test-select-fd.c:
--- a/tes
Bruno Haible wrote:
What if the .exe has another name?
What other names are in common use for this program?
No sure. I'll need to check the MinGW-w64 list and motive.
Some custom variation of it perhaps?
The purpose of your function looks similar to what Mihail Konev
did for the MinGW-w64
Bruno Haible wrote:
+ if (QueryFullProcessImageNameFunc (processHandle, 0, buf, &bufsize))
+{
+ if (strlen (buf) >= 11
+ && strcmp (buf + strlen (buf) - 11, "\\mintty.exe") == 0)
What if the .exe has another name?
The purpose of your function
Darshit Shah wrote:
+# If using Python 2, ensure that at least version 2.7 is used. Older versions
+# are not supported
+if not PYTHON3 or sys.version_info[1] < 7:
+print("Python version must be atleast 2.7. Exiting.")
Shouldn't this be:
if not PYTHON3 and sys.version_info[1] < 7:
--
--
Bruno Haible wrote:
+#if (defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__
+ /* On native Windows, here,
Just curious, which Windows compiler has '__WIN32__'
as a built-in, but not '_WIN32'?
AFAICS, all MinGW's have both. And clang-cl does not have '__WIN32__'.
--
--gv
Tim Rühsen wrote:
Attached is a quick commit with a new lib/pragmas.h. Sorry, I currently
don't have time for anything more (e.g. a module).
These are nice. MSVC also has the '__pragma()' keyword
documented here:
https://msdn.microsoft.com/en-us/library/d9x1s805.aspx
But that would need a f
Hello list.
I'm trying to use Gnulib's from clang-cl C++
compiler. I have no problems with pure C with either clang-cl
or MSVC. But in C++ I get endless troubles with errors like these:
f:/MingW32/src/gnu/gnulib/lib\math.h(2397,36): error: functions that
differ only in their return type can
Bruno Haible wrote:
The answer is: When I use it with kchmviewer, it provides fast scrolling
through the (huge) TOC, a search index, and a fast search facility.
Which is not built-in into browsers and is often emulated with slow JavaScript.
Agreed.
It is also viewable in 'okular', but it sho
Maybe a bit off-topic, but I've created a Compressed HTML-file from the
doc/*.texi files. Using this makefile snippet:
TEXI2HTML ?= py -3 f:/ProgramFiler/Python36/Tools/scripts/texi2html.py
gnulib.chm: gnulib.texi
-mkdir output
$(TEXI2HTML) -H gnulib $< output
hhc gnulib.hhp
(
Bruno Haible wrote:
There are some other trivial stuff in:
./lib/count-leading-zeros.h
./lib/count-one-bits.h
./lib/iconv.in.h
./lib/inttypes.in.h
./lib/localtime-buffer.c
which I'll come back to.
Huh? There were no issues with MSVC 14 in these places in my latest round
of
Paul Eggert wrote:
Hmm, is it because of the '#define __inline' to nothing later on? OK, I can see
where that might be an issue.
Exactly, in glob.c which includes the Windows-SDK function:
__inline struct _TEB *NtCurrentTeb (void)
{
return (struct _TEB *) (ULONG_PTR) __readfsdword (0x
The new files libc-config.h and cdefs.h, break MSVC in
several ways:
1) libc-config.h:
# undef __inline
'__inline' is a built-in reserved word used through-out the MS SDK.
2) MSVC doesn't accept this:
#define libc_hidden_proto(name, attrs...)
Why not simply?
#define libc_hidden_pr
Compiling this new file (using MSVC-2015), give me these errors:
renameat2.c(55): error C2079: 'st' uses undefined struct 'stat'
renameat2.c(212): error C2065: 'file1': undeclared identifier
renameat2.c(212): warning C4047: 'function': 'const char *' differs in levels
of indirection from '
Akash Rawal wrote:
+static HANDLE
+get_hevent()
+{
+ HANDLE res;
+
+ pthread_mutex_lock(&event_pool.lock);
Do you assume and MinGW-w64 here?
Code like this will break in MSVC.
AFAICS, you could use the stuff in
/lib/glthread/*.c
glthread_lock_lock_func() etc.
--
--gv
Tim Rühsen wrote:
Built on MinGW / Win32 the same open sets errno to EACCES.
We currently use a work-around like
+ int rc = open(pathname, flags, mode);
+#ifdef _WIN32
+ if (rc < 0 && errno == EACCES) {
+ DWORD attrs = GetFileAttributes(pathname);
+ if (
Bruno Haible wrote:
You seem to be doing a native Windows compilation with the MSVC include files
and a non-Microsoft compiler [1]. This is not the among usual tested
combinations;
good luck with this adventure :)
clang-cl is just gcc 4.x in disguise AFAICS. I love clang-cl;
it's what gcc/cl
I'm not sure exactly when or how these new warnings from
clang-cl happened (a lot of them):
f:/ProgramFiler-x86/WindowsKits/Include/10.0.15063.0/ucrt/stdlib.h(78,5):
warning: macro expansion producing 'defined' has undefined behavior
[-Wexpansion-to-defined]
#if _CRT_INTERNAL_NONSTDC_
Bruno Haible wrote:
diff --git a/lib/gettext.h b/lib/gettext.h
index 888e2fc..2a12bb6 100644
--- a/lib/gettext.h
+++ b/lib/gettext.h
@@ -18,8 +18,9 @@
#ifndef _LIBGETTEXT_H
#define _LIBGETTEXT_H 1
-/* NLS can be disabled through the configure --disable-nls option. */
-#if ENABLE_NLS
+/* NLS
Paul Eggert wrote:
On 04/19/2017 05:13 AM, Gisle Vanem wrote:
With "%.3a %d", I do get the expected "0x1.922p+1 33".
So are these tests somewhat gcc-centric or what?
Yes. It looks to me like MSVC-2015 is right and glibc is wrong, at least in the
sense of acting like s
Christian Egli wrote:
../tools/gnulib/.libs/libgnutools.a(getopt.o): In function
`process_long_option':
/home/eglic/src/liblouis/tools/gnulib/getopt.c:281: undefined reference to
`flockfile'
/home/eglic/src/liblouis/tools/gnulib/getopt.c:295: undefined reference to
`funlockfile'
collect2: err
When using MSVC-2015 to build the tests/unistdio/test-ulc-*.c files,
I get ASSERT() on all the '%a' formats. E.g. in
unistdio/test-ulc-vasnprintf1.exe
and unistdio/test-ulc-printf1.h (line 195):
char *result =
my_xasprintf ("%a %d", 3.1416015625, 33, 44, 55);
ASSERT (result != NULL
Daniel P. Berrange wrote:
that makes the recv() work, but now poll() just gets into an infinite loop
calling select() over and over again, never reporting that the socket is
now read()able. So something else is now broken. I guess we're now calling
into gnulib's rpl_select() instead of the bare
Pedro Alves wrote:
> Can't see how that can run fine? The compiler will set up the call
> assuming cdecl convention, while the called function has stdcall
> convention.
I would expect the 'reinterpret_cast(::getaddrinfo)' to fix that.
With this little example:
#include
#include
int main
> I've not checked all test-*.cc files for such errors.
Another issue with sys_select.in.h:
test-sys_select-c++.cc
sys/select.h(305): error C2440: 'return': cannot convert from
'int (__cdecl *)(int,fd_set *,fd_set *,fd_set *,timeval *)' to
'gnulib_::_gl_select_wrapper::type'
sys/select.h
I get errors from MSVC in i C++ mode. E.g. in compiling
test-netdb-c++.cc:
netdb.h(189): error C2440: 'return': cannot convert
from 'INT (__stdcall *)(PCSTR,PCSTR,const ADDRINFOA *,PADDRINFOA *)' to
'gnulib_::_gl_getaddrinfo_wrapper::type'
Ditto error for '_gl_freeaddrinfo_wrapper'.
Some
Bruno Haible wrote:
> $ ./gnulib-tool --create-testdir --dir=/tmp/testdir-stdioext --with-tests \
> --single-configure --avoid=havelib-tests \
> fseterr freadable fwritable fbufmode freading fwriting \
> freadptr freadseek freadahead fpurge fseeko ft
Seems this file supports every archaic target in existence, but
not MSVC. I've patched it like:
--- a/lib/fseeko.c 2016-01-30 20:42:16
+++ b/lib/fseeko.c 2016-01-31 10:25:06
@@ -100,7 +100,7 @@
#elif defined EPLAN9/* Plan9 */
if (fp->rp == fp->buf
&& fp->wp == fp->buf)
-
Jim Meyering wrote:
> +# elif HAVE_DECL___ARGV
> + return last_component (__argv);
This should be:
return last_component (*__argv);
Or with a bit more care:
if (*__argv == NULL)
return ("?");
return last_component (__argv);
And in the test:
+int
+main (void)
+{
+ char const *p = g
Jim Meyering wrote:
> From the output of that mingw configure run, it appears they are not
> declared -- at least not in any header included by this particular
> test program:
>
> checking whether program_invocation_name is declared... no
> checking whether program_invocation_short_name is de
John W. Eaton wrote:
It doesn't matter much to me personally, but I think some people would like to
see the result contain only \ on Windows
systems.
So you're on Windows? Then perhaps you can use 'GetFullPathName()'
directly?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa3649
Paul Eggert wrote 22-Jan-2015:
diff --git a/ChangeLog b/ChangeLog
index e0c12d3..8839306 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2015-01-21 Paul Eggert
+
+ getcwd, glob, scandir: port to MSVC
+ Problem reported by Gisle Vanem in:
+ http://lists.gnu.org
I'm getting this error at the link stage (MSVC v18 on Win-8.1):
poll.obj : error LNK2019: unresolved external symbol
_recv_used_without_including_sys_socket_h referenced in function
_windows_compute_revents_socket
poll.obj : error LNK2019: unresolved external symbol
_select_used_wit
In lib/glob.c, the code:
# undef opendir
# undef closedir
causes this link error:
glob.obj : error LNK2019: unresolved external symbol _closedir referenced in
function _glob_in_dir
glob.obj : error LNK2019: unresolved external symbol _opendir referenced in
function _glob_in_dir
I fixed
Pádraig Brady wrote:
Gisle, how does this this version work for you?
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/count-leading-zeros.h;h=5904eb7f
Compiling that, results in some warnings:
count-leading-zeros.h(42) : warning C4083: expected '('; found identifier
'_BitScanRe
Pádraig Brady wrote:
Does the following address the issue for you?
It should drop back to the more generic slow path on 32 bit.
But I do have _BitReverse. That could be an intrinsic.
BTW do we have the same issue with __popcnt64 in count-one-bits.h?
Seems so:
__MACHINEX64(unsigned __int6
I'm on Win-XP (32bit, MSVC v16) and get a link error on a
missing '__BitScanReverse64()' in test-count-leading-zeros.c:.
Here is the dis-asm:
_count_leading_zeros_ll:
pushebp
mov ebp,esp
sub esp,0x0008
X$72:
mov
Pádraig Brady wrote:
I assume if some vendor have 'cosf' it should be undefined
before Gnulib is trying to override or replace it. Not vice
versa. So shouldn't this be:
# if @HAVE_COSF@ || @REPLACE_COSF@
# undef cosf
Well all the ...f() variants seem to be treated like this:
acosf() cos
I'm trying to understand the logic behind the generation
of some statements in math.h (from math.in.h). The MSVC
compiler has cosf() defined as a macro in it's :
#define cosf(x) ((float)cos((double)(x)))
(for x86,C). Then how is Gnulib supposed to replace that?
Since no matter what's put in
Andy Moreton wrote:
Don't expect any C support in MSVC that isn't required by C++ standards.
I don't really care about C-99+ (or let alone C++). I love
MSVC for it's speed compared to any gcc version. And PCB
debug-format and PCH, etc. etc. So please continue to support it.
--
--gv
Hi list.
I managed to build gnulib using MSVC v16 (i.e. Visual Studio
2010 Express). All was okay except for a little C99-feature
(of data after code which my v16 doesn't support).
So can you please apply this patch?
--- orig/lib/fts.c 2014-11-08 12:19:14 +
+++ lib/fts.c2014-11-08
64 matches
Mail list logo
