Re: [autoconf] AmigaOS fork()

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 23 Jun 2001 17:51:54 +0200 > > Paul, this patch was sent later, and you did not comment it. Sorry, I didn't see it. I don't think that patch is necessary. Here are some more detailed comments: > + AC_DEFINE(ac_vfork, vfork, [Define to `vfork'

Re: [autoconf] AmigaOS fork()

>--[Akim Demaille]--<[EMAIL PROTECTED]> > Paul, this patch was sent later, and you did not comment it. Does silence means it is refused? Come on, whoever has some authority on this subject, say something, you aren't Dave Zaroski, are you? > 2001-06-19 Rüdiger Kuhlmann <[EMAIL PROTECTED]> > >

Re: [autoconf] AmigaOS fork()

Paul, this patch was sent later, and you did not comment it. Akim Okay, people, what do you think about this: v--- *grrr* 2001-06-19 Rüdiger Kuhlmann <[EMAIL PROTECTED]> * acfunctions.m

Re: [autoconf] AmigaOS fork()

>--[Eric Siegerman]--<[EMAIL PROTECTED]> > On Mon, Jun 18, 2001 at 03:29:17PM +0200, Rüdiger Kuhlmann wrote: > > [fork + vfork + ac_fork + ac_vfork] > > I guess you know _I_ agree, but "the others" don't seem so. > Suits me just fine. Okay, people, what do you think about this:

Re: [autoconf] AmigaOS fork()

> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> Congrats! Please, next time, check your code for things like `endif' instead of `fi' and so on.

Re: [autoconf] AmigaOS fork()

> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> That looks good to me. Then it does to me. Congrats!

Re: [autoconf] AmigaOS fork()

> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> (This vfork business should all be discussed clearly in the Paul> autoconf documentation, of course -- if anything about vfork can Paul> be discussed clearly. :-) I'm installing the following patch to the Autoconf documentation. Plea

Re: [autoconf] AmigaOS fork()

On Mon, Jun 18, 2001 at 03:29:17PM +0200, Rüdiger Kuhlmann wrote: > [fork + vfork + ac_fork + ac_vfork] > > I guess you know _I_ agree, but "the others" don't seem so. Suits me just fine. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrus

Re: [autoconf] AmigaOS fork()

That looks good to me.

Re: [autoconf] AmigaOS fork()

>--[Alexandre Oliva]--<[EMAIL PROTECTED]> > On Jun 13, 2001, Rüdiger Kuhlmann <[EMAIL PROTECTED]> >wrote: > > Wait, I disagree. If there is no fork() > perhaps we can use a spoon()? Hmm, no, we have to remember ``there's > no spoon'' either. :-) *g* > How about defining our own macro, say ac

Re: [autoconf] AmigaOS fork()

On Jun 13, 2001, Rüdiger Kuhlmann <[EMAIL PROTECTED]> wrote: > Wait, I disagree. If there is no fork() perhaps we can use a spoon()? Hmm, no, we have to remember ``there's no spoon'' either. :-) How about defining our own macro, say ac_fork(), that would be #defined to fork(), if available, o

Re: [autoconf] AmigaOS fork()

2001-06-15 Rüdiger Kuhlmann <[EMAIL PROTECTED]> * acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove AC_DEFINEs and don't guess cross-compilation values. (_AC_FUNC_FORK) New, check whether fork() isn't just a stub. (AC_FUNC_FORK) New, use _AC

Re: [autoconf] AmigaOS fork()

> +If @file{vfork.h} is found, define @code{HAVE_VFORK_H}. If a working > +@code{vfork} is found, define @code{HAVE_WORKING_VFORK}. Otherwise, > +define @code{vfork} to be @code{fork} for backward compatibility. You need to append "with previous versions of @command{autoconf}" here. > +In case

Re: [autoconf] AmigaOS fork()

Hi! Since the discussion stopped, can we agree on the following patch? Feel free to add more documentation on fork() vs vfork() later. 2001-06-15 Rüdiger Kuhlmann <[EMAIL PROTECTED]> * acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove AC_DEFINEs and don't gue

Re: [autoconf] AmigaOS fork()

On Wed, Jun 13, 2001 at 03:28:41PM -0700, Paul Eggert wrote: > > > > Date: Wed, 13 Jun 2001 00:07:55 +0200 > > > > * fork(), that should be a fork() if possible, but if not available, > > > >a vfork() should do the job as well > > > > > > I don't see why this case would ever happen in real c

Re: [autoconf] AmigaOS fork()

> From: Eric Siegerman <[EMAIL PROTECTED]> > Date: Wed, 13 Jun 2001 17:29:52 -0400 > > On Tue, Jun 12, 2001 at 07:42:47PM -0700, Paul Eggert wrote: > > > From: <[EMAIL PROTECTED]> > > > Date: Wed, 13 Jun 2001 00:07:55 +0200 > > > * fork(), that should be a fork() if possible, but if not availabl

Re: [autoconf] AmigaOS fork()

On Tue, Jun 12, 2001 at 07:42:47PM -0700, Paul Eggert wrote: > > From: <[EMAIL PROTECTED]> > > Date: Wed, 13 Jun 2001 00:07:55 +0200 > > This leads to four(!) different cases: > > [...] > > * fork(), that should be a fork() if possible, but if not available, > >a vfork() should do the job as

Re: [autoconf] AmigaOS fork()

On Tue, Jun 12, 2001 at 02:17:32PM -0700, Paul Eggert wrote: > > From: Eric Siegerman <[EMAIL PROTECTED]> > > Date: Tue, 12 Jun 2001 15:02:58 -0400 > > > > you can get away with: > > #define a b > > (or the equivalent using true functions) only if a()'s behaviour > > is a strict subset

Re: why AC_FUNC_WAIT3 is useless (was: AmigaOS fork())

> From: "Paul D. Smith" <[EMAIL PROTECTED]> > Date: 13 Jun 2001 15:03:41 -0400 > > pe> However, this point is somewhat academic. Nobody uses wait3 > pe> anymore > > GNU make uses wait3() if waitpid() doesn't exist, as well. Sorry, I missed that, because I was looking only for instances

Re: [autoconf] AmigaOS fork()

%% Paul Eggert <[EMAIL PROTECTED]> writes: pe> However, this point is somewhat academic. Nobody uses wait3 pe> anymore. (Well, that's not quite true: I just checked all the GNU pe> programs we have here, and Bash uses wait3 if waitpid does not pe> exist -- but Bash doesn't care whether

Re: [autoconf] AmigaOS fork()

> From: <[EMAIL PROTECTED]> > Date: Wed, 13 Jun 2001 11:52:36 +0200 > I don't see why the AC_FUNC_WAIT3 test relies on the parent running at the > same time You're right; I got confused by the 'sleep' in the child, and assumed that it was checking for a race condition. But on second thought tha

Re: [autoconf] AmigaOS fork()

>--[Paul Eggert]--<[EMAIL PROTECTED]> > > > I don't think the uses are portable. > > Wait, why not? > The latest POSIX draft says this: > [...] Okay. > > And if they aren't, would it be okay to change the > > HAVE_WORKING_VFORK to !HAVE_WORKING_FORK? > No. For AC_FUNC_WAIT3 and AC_SYS_RESTART

Re: [autoconf] AmigaOS fork()

On Tue, Jun 12, 2001 at 07:42:47PM -0700, Paul Eggert wrote: > This case is catered to by the usual trick of '#define vfork fork' if > a working vfork is not available. except that the existing test doesn't check if vfork is already #define'd in a header file. -- Thomas E. Dickey <[EMAIL PROTEC

Re: [autoconf] AmigaOS fork()

> From: <[EMAIL PROTECTED]> > Date: Wed, 13 Jun 2001 00:07:55 +0200 > > > I don't think the uses are portable. > > Wait, why not? The latest POSIX draft says this: The vfork() function shall be equivalent to fork(), except that the behavior is undefined if the process created by vfork()

Re: [autoconf] AmigaOS fork()

> From: R. Kuhlmann <[EMAIL PROTECTED]> > Date: Tue, 12 Jun 2001 17:01:08 +0200 > > #define vfork to fork if necessary. to vfork if necessary. There's an echo in that part of the ChangeLog... In the light of the previous message, it seems to me that the patch should not alter AC_FUNC_

Re: [autoconf] AmigaOS fork()

>--[Paul Eggert]--<[EMAIL PROTECTED]> > ... Kuhlmann's patch ... *giggle* feel free to use my first name. > I don't think the uses are portable. Wait, why not? And if they aren't, would it be okay to change the HAVE_WORKING_VFORK to !HAVE_WORKING_FORK? > > The forkvfork() idea would be safes

Re: [autoconf] AmigaOS fork()

> From: Eric Siegerman <[EMAIL PROTECTED]> > Date: Tue, 12 Jun 2001 15:02:58 -0400 > > you can get away with: > #define a b > (or the equivalent using true functions) only if a()'s behaviour > is a strict subset of b()'s. That's not the case with > fork/vfork, in either direction. B

Re: [autoconf] AmigaOS fork()

ork() for any purpose except as a prelude to an > immediate call to a function from the exec family, or to _exit(), is not > advised. Again, autoconf isn't in a position to know what the child process is going to do. > But > apparently AmigaOS has a working vfork but not a worki

Re: [autoconf] AmigaOS fork()

> Actually, the original definition of 'vfork' said that one should not > rely on this behavior. And in the latest POSIX draft (POSIX > 1003.1-200x draft 5) the rationale states simply "On some > implementations, vfork() is equivalent to fork()." Actually, the latest draft is nr 6 (April 2001).

Re: [autoconf] AmigaOS fork()

Hi! >--[Paul Eggert]--<[EMAIL PROTECTED]> > * The documentation says that AC_FUNC_FORK "only checks whether `fork' > is just a stub." But that's not correct when not cross-compiling: > AC_FUNC_FORK actually runs a program that tries to fork. Okay, doc fixed. > * AC_FUNC_FORK outputs a wa

Re: [autoconf] AmigaOS fork()

> From: Eric Siegerman <[EMAIL PROTECTED]> > Date: Mon, 11 Jun 2001 21:19:22 -0400 > > Paul Eggert wrote: > > the Unix tradition is that code that uses 'vfork' can be safely > > changed to use 'fork' if you like. > > If this is a tradition, it's a bad one. Recall that with vfork, > the chil

Re: [autoconf] AmigaOS fork()

On Mon, Jun 11, 2001 at 05:31:41PM -0700, Paul Eggert wrote: > [...] the Unix tradition is > that code that uses 'vfork' can be safely changed to use 'fork' if > you like. If this is a tradition, it's a bad one. Recall that with vfork, the child's memory writes, up till it calls some varia

Re: [autoconf] AmigaOS fork()

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 11 Jun 2001 23:07:29 +0200 > > I wanted to have some feedback from Jim and Paul... If you two guys > don't have time to give a look at it, than I'll apply it on Wednesday. I read through

Re: [autoconf] AmigaOS fork()

| >--[Rüdiger Kuhlmann]--<[EMAIL PROTECTED]> | | > 2001-06-01 Rüdiger Kuhlmann <[EMAIL PROTECTED]> | > | > * acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove | > AC_DEFINEs and don't guess cross-compilation values. | > (_AC_FUNC_FORK) New, check whether fork()

Re: [autoconf] AmigaOS fork()

>--[Rüdiger Kuhlmann]--<[EMAIL PROTECTED]> > 2001-06-01 Rüdiger Kuhlmann <[EMAIL PROTECTED]> > > * acfunctions.m4: (AC_FUNC_VFORK) renamed to _AC_FUNC_VFORK. Remove > AC_DEFINEs and don't guess cross-compilation values. > (_AC_FUNC_FORK) New, check whether fork() isn't ju

Re: [autoconf] AmigaOS fork()

>--[Akim Demaille]--<[EMAIL PROTECTED]> > > | > don't know enough about vfork and fork to speak intelligently here, > | > but I seem to understand that using AC_REPLACE_FUNCS would be better > | > suited then, no? I mean, from the user point of view, not for the > | > tests themselves. > | What

Re: [autoconf] AmigaOS fork()

| > don't know enough about vfork and fork to speak intelligently here, | > but I seem to understand that using AC_REPLACE_FUNCS would be better | > suited then, no? I mean, from the user point of view, not for the | > tests themselves. | | What do you mean? If you don't have a fork(), you can'

Re: [autoconf] AmigaOS fork()

>--[Akim Demaille]--<[EMAIL PROTECTED]> > don't know enough about vfork and fork to speak intelligently here, > but I seem to understand that using AC_REPLACE_FUNCS would be better > suited then, no? I mean, from the user point of view, not for the > tests themselves. What do you mean? If you

Re: [autoconf] AmigaOS fork()

> "Rüdiger" == Rüdiger Kuhlmann <[EMAIL PROTECTED]> >writes: Rüdiger> So we need something like AC_MSG_CROSS_WARN that basically Rüdiger> does _AC_ECHO_N([[CROSS] ]) _AC_ECHO_N([[CROSS] ], Rüdiger> AS_MESSAGE_LOG_FD) and maybe outputs a warning at the end of Rüdiger> configure, that some val

Re: [autoconf] AmigaOS fork()

Thanks for your prompt reply! | No. This would be wrong. Then I'd better #define fork to be vfork. But vfork | is not necessarily a replacement for fork. But for the tests at hand, it is. | | Another idea would be to add | | #if HAVE_WORKING_FORK | #define forkvfork fork | #else | #if HAVE_WO

Re: [autoconf] AmigaOS fork()

>--[Tim Van Holder]--<[EMAIL PROTECTED]> > On 31 May 2001 15:15:49 +0200, Rüdiger Kuhlmann wrote: > Akim was talking about the 'case "$host"', I think. > The problem is that since we are testing whether a function works, we > need to _run_ that function. When cross-compiling, this is not > poss

Re: [autoconf] AmigaOS fork()

On 31 May 2001 15:15:49 +0200, Rüdiger Kuhlmann wrote: > > > | + if (fork() < 0) > > | +exit (1); > > > No way to actually *test* the feature? > > There _is_ a test. Look carefully. If fork() "always" fails, > it is a stub. If the fork() succeeds, it is not. Akim was talki

Re: [autoconf] AmigaOS fork()

>--[Akim Demaille]--<[EMAIL PROTECTED]> > I'll wait for some input from Alexandre, Jim or Paul on this one. > | >--[Tim Van Holder]--<[EMAIL PROTECTED]> > | Okay, what about this: It doesn't #define fork anymore, but HAVE_FORK if it > | works. Then the program has to check this itself. > I pre

Re: [autoconf] AmigaOS fork()

I'll wait for some input from Alexandre, Jim or Paul on this one. | >--[Tim Van Holder]--<[EMAIL PROTECTED]> | | > For the cross-compiling case, I think | | Okay, what about this: It doesn't #define fork anymore, but HAVE_FORK if it | works. Then the program has to check this itself. I prefer

Re: AmigaOS fork()

Rüdiger Kuhlmann writes: > [Rüdiger Kuhlmann, please stop mangling the Subject: line. This is highly annoying.]

Re: [autoconf] AmigaOS fork()

Ehm, what do you want me to change to have this patch accepted? Yours, Rüdiger. -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi

Re: [autoconf] AmigaOS fork()

>--[Russ Allbery]--<[EMAIL PROTECTED]> > Peter Eisentraut <[EMAIL PROTECTED]> writes: [Yes, I do read the mailing lists I'm writing to. I even set a Mail-Followup-To:] > > The key question here is, if a program requires fork(), would it > > normally work with Amiga's vfork()? My guess is no, s

Re: [autoconf] AmigaOS fork()

Peter Eisentraut <[EMAIL PROTECTED]> writes: > The key question here is, if a program requires fork(), would it > normally work with Amiga's vfork()? My guess is no, so this patch would > not be correct. I like the idea of testing for fork() and making sure it works. The only part I disagree w

Re: [autoconf] AmigaOS fork()

Rüdiger Kuhlmann writes: > Okay, what about this: It doesn't #define fork anymore, but HAVE_FORK if it > works. Then the program has to check this itself. > > 2001-05-24 Rüdiger Kuhlmann <[EMAIL PROTECTED]> > > * acfunctions.m4: (AC_FUNC_FORK) New, check whether fork() isn't just >

Re: [autoconf] AmigaOS fork()

>--[Tim Van Holder]--<[EMAIL PROTECTED]> > For the cross-compiling case, I think Okay, what about this: It doesn't #define fork anymore, but HAVE_FORK if it works. Then the program has to check this itself. 2001-05-24 Rüdiger Kuhlmann <[EMAIL PROTECTED]> * acfunctions.m4: (AC_FUNC_FOR

Re: AmigaOS fork()

> +/* On AmigaOS, fork() isn't implemented due to missing MP. */ > +int main () > +{ > + if (fork() < 0) > +exit (1); > + exit (0); > +}], > +[ac_cv_func_fork_works=yes], > +[ac_cv_func_fork_works=no], > +[AC

Re: AmigaOS fork()

> vfork() is normally a very different function than fork(), with > significantly different and much more dangerous behavior if it is not > immediately followed by an exec(). Is that the case on Amiga, or is it > just a misnamed fork()? AmigaOS cannot have fork() due to lack of virtual memory

Re: AmigaOS fork()

Rüdiger Kuhlmann <[EMAIL PROTECTED]> writes: > Since we've autoconf 2.50 now, maybe it's time to come up with some > not-so-important issues. The problem at hand is that under AmigaOS, the > fork() function always returns EONOSYS (IIRC), in other words, there is > no spoon(), due to limitations t

AmigaOS fork()

STD_H +# include +#endif +/* On AmigaOS, fork() isn't implemented due to missing MP. */ +int main () +{ + if (fork() < 0) +exit (1); + exit (0); +}], +[ac_cv_func_fork_works=yes], +[ac_cv_func_fork_works=no], +[AC_CHECK_FUNC(fork) +AC_COMPILE_IF