GNU bug report logs - #18237
Small fix for MSDOS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18237 in the body.
You can then email your comments to 18237 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-emacs <bug-emacs <at> gnu.org>
Subject: Small fix for MSDOS
Date: Sun, 10 Aug 2014 17:40:24 +0100

[Message part 1 (text/plain, inline)]

The following patch helps in the case when a sockets library is installed;
in my case, ls080b.zip from the DJGPP site:

=== modified file 'src/msdos.c'
--- src/msdos.c    2014-08-09 16:12:33 +0000
+++ src/msdos.c    2014-08-09 21:51:56 +0000
@@ -4016,7 +4017,7 @@
 #endif


-#ifndef HAVE_SELECT
+#ifndef HAVE_SYS_SELECT_H
 #include "sysselect.h"

 /* This yields the rest of the current time slice to the task manager.


The reasoning is that having select doesn't imply having the sys/select.h
functionality that the following code emulates.

Does that look OK to install?

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #8 received at 18237 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18237 <at> debbugs.gnu.org
Subject: Re: bug#18237: Small fix for MSDOS
Date: Sun, 10 Aug 2014 21:02:56 +0300

> Date: Sun, 10 Aug 2014 17:40:24 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> 
> The following patch helps in the case when a sockets library is installed;
> in my case, ls080b.zip from the DJGPP site:
> 
> === modified file 'src/msdos.c'
> --- src/msdos.c    2014-08-09 16:12:33 +0000
> +++ src/msdos.c    2014-08-09 21:51:56 +0000
> @@ -4016,7 +4017,7 @@
>  #endif
> 
> 
> -#ifndef HAVE_SELECT
> +#ifndef HAVE_SYS_SELECT_H
>  #include "sysselect.h"
> 
>  /* This yields the rest of the current time slice to the task manager.
> 
> 
> The reasoning is that having select doesn't imply having the sys/select.h
> functionality that the following code emulates.
> 
> Does that look OK to install?

You didn't tell enough details, so I don't understand why the change
is needed, and why it is OK not to test HAVE_SELECT at all here.  (I
don't have ls080b.zip installed.)  Please tell what problems did you
see with the original code, and let's take it from there.

Thanks.

Message #11 received at 18237 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18237 <at> debbugs.gnu.org
Subject: Re: bug#18237: Small fix for MSDOS
Date: Sun, 10 Aug 2014 19:19:24 +0100

[Message part 1 (text/plain, inline)]

On 10 August 2014 19:02, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sun, 10 Aug 2014 17:40:24 +0100
> > From: Reuben Thomas <rrt <at> sc3d.org>
> >
> > The following patch helps in the case when a sockets library is
> installed;
> > in my case, ls080b.zip from the DJGPP site:
> >
> > === modified file 'src/msdos.c'
> > --- src/msdos.c    2014-08-09 16:12:33 +0000
> > +++ src/msdos.c    2014-08-09 21:51:56 +0000
> > @@ -4016,7 +4017,7 @@
> >  #endif
> >
> >
> > -#ifndef HAVE_SELECT
> > +#ifndef HAVE_SYS_SELECT_H
> >  #include "sysselect.h"
> >
> >  /* This yields the rest of the current time slice to the task manager.
> >
> >
> > The reasoning is that having select doesn't imply having the sys/select.h
> > functionality that the following code emulates.
> >
> > Does that look OK to install?
>
> You didn't tell enough details, so I don't understand why the change
> is needed, and why it is OK not to test HAVE_SELECT at all here.  (I
> don't have ls080b.zip installed.)  Please tell what problems did you
> see with the original code, and let's take it from there.
>

libsocket is a sockets implementation:
http://rich.phekda.org/richdawe/lsck/lsck_dl.htm

When it is installed, configure correctly detects that select is available,
and sets HAVE_SELECT. However, libsocket has no sys/select.h, nor does it
implement sys_select.

Hence, at present, when I build using ./configure && make for DOS with
libsocket installed, HAVE_SELECT is defined to 1, so the MS-DOS
implementation of sys_select in msdos.c is not compiled. Later, the linker
is unable to find sys_select, and the build fails.

I think you're also saying that I should test both HAVE_SELECT &&
HAVE_SYS_SELECT_H therefore? You're probably right, I (incorrectly?)
assumed that if HAVE_SYS_SELECT_H is true, then HAVE_SELECT would be too.

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #14 received at 18237 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18237 <at> debbugs.gnu.org
Subject: Re: bug#18237: Small fix for MSDOS
Date: Sun, 10 Aug 2014 21:26:47 +0300

> Date: Sun, 10 Aug 2014 19:19:24 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: 18237 <at> debbugs.gnu.org
> 
> When it is installed, configure correctly detects that select is available,
> and sets HAVE_SELECT. However, libsocket has no sys/select.h, nor does it
> implement sys_select.
> 
> Hence, at present, when I build using ./configure && make for DOS with
> libsocket installed, HAVE_SELECT is defined to 1, so the MS-DOS
> implementation of sys_select in msdos.c is not compiled. Later, the linker
> is unable to find sys_select, and the build fails.

So it's a consequence of trying to configure using the Posix configure
script.

I'd prefer that all the changes for such a build be committed at once
together, not bit by bit, and only if you eventually succeed to
produce a working binary using this method.

> I think you're also saying that I should test both HAVE_SELECT &&
> HAVE_SYS_SELECT_H therefore?

Yes, at the very least.  But let's delay this until you have gone all
the way to building Emacs using this method.  We won't know all of the
implications until you do.

Message #19 received at 18237-done <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18237-done <at> debbugs.gnu.org
Subject: Re: bug#18237: Small fix for MSDOS
Date: Sun, 10 Aug 2014 19:42:14 +0100

[Message part 1 (text/plain, inline)]

On 10 August 2014 19:26, Eli Zaretskii <eliz <at> gnu.org> wrote:

>
> I'd prefer that all the changes for such a build be committed at once
> together, not bit by bit, and only if you eventually succeed to
> produce a working binary using this method.
>

Sorry, I was trying to separate my patch into parts with different
implications (e.g. no effect on the current DOS build system; some effect
on that system but not more generally; more general changes); but instead
I'll concentrate on producing a single patch that, as you say, results in a
working binary.


>  > I think you're also saying that I should test both HAVE_SELECT &&
> > HAVE_SYS_SELECT_H therefore?
>
> Yes, at the very least.


Noted.


>  But let's delay this until you have gone all
> the way to building Emacs using this method.  We won't know all of the
> implications until you do.
>

Sure, OK.

I am closing this bug; since you diagnosed my other patch submission as a
more general bug in configuration, I'll look into a fix for it at that
level.

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #22 received at 18237 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18237 <at> debbugs.gnu.org
Subject: Re: bug#18237: Small fix for MSDOS
Date: Sun, 10 Aug 2014 22:05:15 +0300

> Date: Sun, 10 Aug 2014 19:42:14 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: 18237-done <at> debbugs.gnu.org
> 
> > I'd prefer that all the changes for such a build be committed at once
> > together, not bit by bit, and only if you eventually succeed to
> > produce a working binary using this method.
> 
> Sorry, I was trying to separate my patch into parts with different
> implications (e.g. no effect on the current DOS build system; some effect
> on that system but not more generally; more general changes); but instead
> I'll concentrate on producing a single patch that, as you say, results in a
> working binary.

Yes, I'd prefer that.  This makes it easier to consider all of its
implications at once.  (You can, of course, make separate small
commits on your feature branch, as you work on this; then they will
all be merged onto the trunk as a single merge-commit.)

> I am closing this bug; since you diagnosed my other patch submission as a
> more general bug in configuration, I'll look into a fix for it at that
> level.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.