Paul Eggert wrote:
> fnmatch now depends on a module wmempcpy that does not exist, causing the
> bootstrap to fail.
Fixed the 'fnmatch' dependencies like this.
2020-05-30 Bruno Haible
wmemchr: Relicense under LGPLv2+.
* modules/wmemchr (License): Set to LGPLv2+.
2020-05-30
Hi Paul,
> Oops, I found a problem when trying to use that patch with coreutils: fnmatch
> now depends on a module wmempcpy that does not exist, causing the bootstrap
> to fail.
Oops, you can bet that I tested this patch only on glibc systems. :-(
Working on it now...
> Come to think of it, cor
On 5/29/20 1:54 PM, Paul Eggert wrote:
> On 5/29/20 5:02 AM, Bruno Haible wrote:
>
>> Paul, is this OK from the perspective of a future merge with glibc?
>
> Yes, it's an improvement in that department; thanks.
>
Oops, I found a problem when trying to use that patch with coreutils: fnmatch
now
On Sat, May 30, 2020 at 7:06 PM Bruno Haible wrote:
>
> On Mac OS X, the header file is not self-contained.
>
> On Mac OS X 10.5:
>
> In file included from ./sys/random.h:28,
>from ../../gllib/getrandom.c:22:
> /usr/include/sys/random.h:37: error: syntax error before ‘u_in
The list of crypto devices in m4/gc-random.m4 is from 2006.
I get test failures of module 'getrandom' on current versions of
NetBSD and OpenBSD (NetBSD 7.0 and 9.0, and OpenBSD 6.5, to be precise).
These platforms have the quasi-standard /dev/random and /dev/urandom
meanwhile. No more /dev/srandom
On Mac OS X, the header file is not self-contained.
On Mac OS X 10.5:
In file included from ./sys/random.h:28,
from ../../gllib/getrandom.c:22:
/usr/include/sys/random.h:37: error: syntax error before ‘u_int’
It needs to be included first.
On Mac OS X 10.13:
In file
On 5/30/20 5:58 AM, Bruno Haible wrote:
> There are several problems with this commit:
> - It causes a Continuous Integration failure.
> - It partially overlaps with the crypto/gc-random module.
> - The ChangeLog entry lists files that were not committed.
> - It conflicts with the declarati
> On May 30, 2020 5:47 PM Bruno Haible wrote:
>
>
> Steve Lhomme wrote:
> > > > You can see one of the last commit is adding
> > > > GetFileInformationByHandle() for example. But that means anyone
> > > > building with an older version of winstorecompat cannot rely on this
> > > > helper.
>
Steve Lhomme wrote:
> > > You can see one of the last commit is adding GetFileInformationByHandle()
> > > for example. But that means anyone building with an older version of
> > > winstorecompat cannot rely on this helper.
> >
> > That's not a good enough reason for adding this code to gnulib.
Steve Lhomme wrote:
> Microsoft.com doesn't document the function as LoadLibrary anymore. There is
> LoadLibraryA and LoadLibraryW.
> https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya
> https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-li
Now that we have a module with test cases, we see that
there is a conflict with the function defined on Solaris 11.3 and newer:
../gllib/sys/random.h: In member function
‘gnulib::_gl_getrandom_wrapper::operator gnulib::_gl_getrandom_wrapper::type()
const’:
../gllib/sys/random.h:535:1: error: in
> On May 30, 2020 4:35 PM Bruno Haible wrote:
>
>
> Steve Lhomme wrote:
> > > So, it makes sense to put your code into a separate library, that
> > > implements
> > > Windows API on top of UWP API. Gnulib focuses (partially) on providing the
> > > POSIX and glibc API on top of the Windows API.
> On May 30, 2020 4:31 PM Bruno Haible wrote:
>
>
> Steve Lhomme wrote:
> > Why not use the proper call in the first place rather than use a define ?
> > It could be useful in a generic header used by all to make sure everyone
> > uses the right thing. But since you need to edit each file it wo
Steve Lhomme wrote:
> > So, it makes sense to put your code into a separate library, that implements
> > Windows API on top of UWP API. Gnulib focuses (partially) on providing the
> > POSIX and glibc API on top of the Windows API.
>
> That's the case in mingw-w64 which has winstorecompat to mimick
Steve Lhomme wrote:
> Why not use the proper call in the first place rather than use a define ?
> It could be useful in a generic header used by all to make sure everyone
> uses the right thing. But since you need to edit each file it would be
> cleaner not to use any define at all and use the prop
On platforms which do have a that does not declare
getrandom() - such as Mac OS X 10.5 or HP-UX 11, gnulib should not override
the system's , but augment it. Otherwise we hide system
functions that the user may want to use.
Also, the getrandom() declaration lacks an 'extern "C"' marker in C++ mod
> On May 30, 2020 11:41 AM Bruno Haible wrote:
>
>
> Hi,
>
> Steve Lhomme wrote:
> > GetFileInformationByHandle() cannot be called. But the same information can
> > be
> > gathered via calls to GetFileInformationByHandleEx() which is allowed.
>
> I am understanding from [1] that Microsoft is
The getrandom module produces a Continuous Integration failure,
see https://gitlab.com/gnulib/gnulib-ci/-/jobs/574033012 . Namely:
In file included from getentropy.c:24:0:
./sys/random.h:8:9: error: conflicting types for 'getrandom'
ssize_t getrandom (void *, size_t, unsigned int);
There are several problems with this commit:
- It causes a Continuous Integration failure.
- It partially overlaps with the crypto/gc-random module.
- The ChangeLog entry lists files that were not committed.
- It conflicts with the declaration on Solaris 11.3 and newer.
- It adds a new he
Why not use the proper call in the first place rather than use a define ?
It could be useful in a generic header used by all to make sure everyone uses
the right thing. But since you need to edit each file it would be cleaner not
to use any define at all and use the proper functions and structure
I think that's the other way around.
_UNICODE is meant to be used with tchar.h. I found 41 instances in a recent SDK.
UNICODE is the more generic term to chose between ANSI or WIDE API calls (if
you don't force them directly). I found 4123 instances in the same SDK.
So IMO the proper way is to u
On Sat, May 30, 2020 at 8:17 AM Bruno Haible wrote:
>
> A testdir for module 'crypto/gc-random' produces a link error
> on MSVC 14:
>
> libgnu.a(gc-gnulib.obj) : error LNK2019: unresolved external symbol
> __imp_CryptAcquireContextA referenced in function gc_init
> libgnu.a(gc-gnulib.obj) : error
A testdir for module 'crypto/gc-random' produces a link error
on MSVC 14:
libgnu.a(gc-gnulib.obj) : error LNK2019: unresolved external symbol
__imp_CryptAcquireContextA referenced in function gc_init
libgnu.a(gc-gnulib.obj) : error LNK2019: unresolved external symbol
__imp_CryptReleaseContext re
On Sat, May 30, 2020 at 5:16 AM Bruno Haible wrote:
>
> I wrote:
> > some types depend on
> > whether UNICODE is defined or not [1].
>
> Some functions also depend whether UNICODE is defined or not.
>
> Since UWP applications are meant to defined the macro UNICODE, but we want
> Gnulib to produce
Hi,
Steve Lhomme wrote:
> GetFileInformationByHandle() cannot be called. But the same information can be
> gathered via calls to GetFileInformationByHandleEx() which is allowed.
I am understanding from [1] that Microsoft is augmenting the list of allowed
functions in UWP over time, and that ultim
Steve Lhomme wrote:
> LoadLibrary is forbidden in such apps (can only load DLLs from within the app
> package).
> The API entries are available to all apps linking with the Windows API as
> found
> here:
> https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
Done differently, without ref
I wrote:
> some types depend on
> whether UNICODE is defined or not [1].
Some functions also depend whether UNICODE is defined or not.
Since UWP applications are meant to defined the macro UNICODE, but we want
Gnulib to produce the same code, regardless whether UNICODE is defined or not,
we need
A testdir for module 'physmem' produces compilation errors with MSVC 14:
- It includes , but this header file does not exist in MSVC.
- It uses the undefined type 'WINBOOL'.
This patch fixes it.
2020-05-30 Bruno Haible
physmem: Fix compilation errors on MSVC.
* lib/physmem.c
28 matches
Mail list logo
