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.c
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
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 math.h:
#define cosf(x) ((float)cos((double)(x)))
(for x86,C). Then how is Gnulib supposed to replace that?
Since no matter what's
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()
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
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
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
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
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 Eggertegg...@cs.ucla.edu
+
+ getcwd, glob, scandir: port to MSVC
+ Problem reported by Gisle Vanem in:
+ http
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?
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
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 =
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)
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
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
> 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'
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
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
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 !=
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
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
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
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
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
Akash Rawal wrote:
+static HANDLE
+get_hevent()
+{
+ HANDLE res;
+
+ pthread_mutex_lock(_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
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
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
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
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
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:
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
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
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:
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, ))
+{
+ if (strlen (buf) >= 11
+ && strcmp (buf + strlen (buf) - 11, "\\mintty.exe") == 0)
What if the .exe has another name?
The purpose of your function looks
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:
---
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
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
+#
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,
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
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,
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?
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
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:
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
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
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
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
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
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:
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"
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
@@
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.
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'
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
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 'time.in
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 (, 1);
and then 'timespec_getres()' calls
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
60 matches
Mail list logo
