Hi Peter,
On Mar 19 13:45, Peter Foley wrote:
> G++ 6.0 can assert that the this pointer is non-null for member functions.
Maybe, but if it compains, it's bound to find false positives...
> @@ -502,7 +502,7 @@ fhandler_dev_dsp::Audio_out::buf_info (audio_buf_info *p,
>
On Mar 23 09:34, Peter Foley wrote:
> Add an option to not require a mingw compiler when bootstrapping a cross
> toolchain.
> Defaults to existing behavior.
> Also update some obsolete macros.
Applied with changes. The below check was skewed.
> +if test "x$with_mingw_progs" != xyes; then
> +
On Mar 23 09:34, Peter Foley wrote:
> When building cygwin in a combined tree with binutils,
> the just-built windres cannot find the just-buit gcc automatically.
> Parse the CC env variable to use the correct compiler, rather then
> falling back to the build-system's gcc which does not define the
On Wed, Mar 30, 2016 at 8:31 AM, Corinna Vinschen
wrote:
> Are you sure this works as desired? In my standard cross build
> environment, the only -B option added here is
>
> --preprocessor-arg=-B/build/cygwin/x86_64/vanilla/x86_64-pc-cygwin/newlib/
The only case in which -B is needed at all is
On Wed, Mar 30, 2016 at 8:11 AM, Corinna Vinschen
wrote:
> Applied with changes. The below check was skewed.
>
>> +if test "x$with_mingw_progs" != xyes; then
>> +AC_CONFIG_SUBDIRS([utils lsaauth])
>> +fi
Whoops, good catch.
On Wed, Mar 30, 2016 at 7:24 AM, Corinna Vinschen
wrote:
> Hi Peter,
>
> On Mar 19 13:45, Peter Foley wrote:
>> G++ 6.0 can assert that the this pointer is non-null for member functions.
>
> Maybe, but if it compains, it's bound to find false positives...
>
Alright, I'll take a closer look at thi
The type for the ip_tos member was typoed, fix it.
winsup/cygwin/ChangeLog:
include/netinet/ip.h: fix type of ip_tos
Signed-off-by: Peter Foley
---
winsup/cygwin/include/netinet/ip.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/include/netinet/ip.h
b/winsup
On Mar 30 09:15, Peter Foley wrote:
> The type for the ip_tos member was typoed, fix it.
>
> winsup/cygwin/ChangeLog:
> include/netinet/ip.h: fix type of ip_tos
Thanks for catching. Applied.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer
On Mar 23 09:34, Peter Foley wrote:
> When building cygwin in a combined tree with binutils,
> the just-built windres cannot find the just-buit gcc automatically.
> Parse the CC env variable to use the correct compiler, rather then
> falling back to the build-system's gcc which does not define the
In preparation to protect fork() against dll- and exe-updates, even for
the main executable and cygwin1.dll store the file name as full NT path,
and keep handles to the files open for subsequent hardlink creation.
Create the child process using the main executable's file name converted
from the ful
Hi,
this is the updated and split series of patches to use hardlinks
for creating the child process by fork(), in reply to
https://cygwin.com/ml/cygwin-developers/2016-01/msg2.html
https://cygwin.com/ml/cygwin-developers/2016-03/msg5.html
http://thread.gmane.org/gmane.os.cygwin.devel/1378
To support in-cygwin package managers, the fork() implementation must
not rely on .exe and .dll files to stay in their original location, as
the package manager's job is to replace these files. Instead, we use
the hardlinks to the original binaries in /var/run/cygfork/ to create
the child process
In preparation to protect fork() against dll- and exe-updates, store
any dll file name as full NT path. Additionally, keep a file handle
open for each loaded dll file for subsequent hardlink creation. The
earlier we open a handle to the dll file, the lower is the chance the
dll file has been rena
In preparation to protect fork() against dll- and exe-updates, create
hardlinks to the main executable and each loaded dll in subdirectories
of /var/run/cygfork/, if that one exists on the NTFS file system.
The directory names consist of the user sid, the main executable's NTFS
IndexNumber, and th
On 03/30/2016 11:53 AM, Michael Haubenwallner wrote:
> Hi,
>
> this is the updated and split series of patches to use hardlinks
> for creating the child process by fork(), in reply to
> https://cygwin.com/ml/cygwin-developers/2016-01/msg2.html
> https://cygwin.com/ml/cygwin-developers/2016-0
On 2016-03-30 13:53, Michael Haubenwallner wrote:
To support in-cygwin package managers, the fork() implementation must
not rely on .exe and .dll files to stay in their original location, as
the package manager's job is to replace these files. Instead, we use
the hardlinks to the original binari
On 03/30/2016 08:55 PM, Daniel Colascione wrote:
>
>
> On 03/30/2016 11:53 AM, Michael Haubenwallner wrote:
>> Hi,
>>
>> this is the updated and split series of patches to use hardlinks
>> for creating the child process by fork(), in reply to
>> https://cygwin.com/ml/cygwin-developers/2016-01/msg
On 03/30/2016 09:04 PM, Yaakov Selkowitz wrote:
> On 2016-03-30 13:53, Michael Haubenwallner wrote:
>> To support in-cygwin package managers, the fork() implementation must
>> not rely on .exe and .dll files to stay in their original location, as
>> the package manager's job is to replace these fil
To avoid the need for each process to check the filesystem to detect
that hardlink creation is impossible or disabled, cache this fact in
shared memory. Removing cygfork directory while in use does disable
hardlinks creation. To (re-)enable hardlinks creation, the cygfork
directory has to exist b
* faq-api.xml: Mention hardlink creation by fork.
* highlights.xml: Describe hardlink creation.
---
winsup/doc/faq-api.xml| 5 +
winsup/doc/highlights.xml | 41 +
2 files changed, 46 insertions(+)
diff --git a/winsup/doc/faq-api.xml
20 matches
Mail list logo
