From: amit t. <ami...@gm...> - 2009-11-12 10:02:04
|
Hi, I am newbie in Msys & Mingw. I am trying to install bison 4.2.1,which gives me error saying " undefined reference to fork" in /lib/subpipe.c I am using following packages :- - w32api-3.13-mingw32-dev - binutils-2.20-1-mingw32 - gcc-core-3.4.5-20060117-3 - make-3.81-20090914-mingw32 - msys-1.0.11 Can anybody help me regarding this? Regards Amit Tandial |
From: JonY <jo...@us...> - 2009-11-12 11:38:09
|
On 11/12/2009 18:01, amit tandial wrote: > Hi, > I am newbie in Msys& Mingw. > I am trying to install bison 4.2.1,which gives me error saying " undefined > reference to fork" in /lib/subpipe.c > > I am using following packages :- > > - w32api-3.13-mingw32-dev > - binutils-2.20-1-mingw32 > - gcc-core-3.4.5-20060117-3 > - make-3.81-20090914-mingw32 > - msys-1.0.11 > > Can anybody help me regarding this? > > Regards > Amit Tandial > Hi, Windows and by extension MinGW doesn't have fork() functionality. The solution is to use msysdvlpr to build bison for MSYS or to switch entirely to Cygwin (MSYS doesn't play well with Cygwin exectables). |
From: amit t. <ami...@gm...> - 2009-11-12 12:10:06
|
Thanks JonY. Temporarily, i have added bison's binaries itself in msys folder. Regrads Amit Tandial On Thu, Nov 12, 2009 at 5:07 PM, JonY <jo...@us...> wrote: > On 11/12/2009 18:01, amit tandial wrote: > > Hi, > > I am newbie in Msys& Mingw. > > I am trying to install bison 4.2.1,which gives me error saying " > undefined > > reference to fork" in /lib/subpipe.c > > > > I am using following packages :- > > > > - w32api-3.13-mingw32-dev > > - binutils-2.20-1-mingw32 > > - gcc-core-3.4.5-20060117-3 > > - make-3.81-20090914-mingw32 > > - msys-1.0.11 > > > > Can anybody help me regarding this? > > > > Regards > > Amit Tandial > > > > Hi, > > Windows and by extension MinGW doesn't have fork() functionality. > > The solution is to use msysdvlpr to build bison for MSYS or to switch > entirely to Cygwin (MSYS doesn't play well with Cygwin exectables). > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Charles W. <cwi...@us...> - 2009-11-12 12:33:07
|
amit tandial wrote: > Hi, > I am newbie in Msys & Mingw. > I am trying to install bison 4.2.1,which gives me error saying " > undefined reference to fork" in /lib/subpipe.c > > I am using following packages :- > > - w32api-3.13-mingw32-dev > - binutils-2.20-1-mingw32 > - gcc-core-3.4.5-20060117-3 > - make-3.81-20090914-mingw32 > - msys-1.0.11 (A) I'll assume you mean bison-2.4.1. There's no such thing as bison-4.2.1. (B) why don't you just install the pre-compiled MSYS version: http://downloads.sourceforge.net/mingw/bison-2.4.1-1-msys-1.0.11-bin.tar.lzma http://downloads.sourceforge.net/mingw/bison-2.4.1-1-msys-1.0.11-rtm.tar.lzma -- Chuck |
From: Vasili B. <vas...@gm...> - 2009-11-12 12:49:26
Attachments:
bison-2.4.1.diff
|
Amit, Here is the .diff I use to make bison working on Win32. Patch your bison source tree with it. Then, compile it as usual. It will move location of bison support files from directory <prefix>/share/bison to <location-of-bison.exe>/bison.dir Also, you will need m4.exe somewhere in your %PATH%. BTW, I tried to post this patch to bison ML several years ago, the response was they aren't interested in native Win32 support... |
From: amit t. <ami...@gm...> - 2009-11-12 13:02:12
|
Thanks everybody for your response. One more request, very similar to previous one. While compiling libgsm1.0.12,getting an error " undefined reference to fchmod()". Does anybody know,how to fix it. -Regards Amit tandial On Thu, Nov 12, 2009 at 5:37 PM, Vasili Burdo <vas...@gm...>wrote: > Amit, > > Here is the .diff I use to make bison working on Win32. Patch your bison > source tree with it. Then, compile it as usual. > > It will move location of bison support files from directory > <prefix>/share/bison to <location-of-bison.exe>/bison.dir > > Also, you will need m4.exe somewhere in your %PATH%. > > BTW, I tried to post this patch to bison ML several years ago, the response > was they aren't interested in native Win32 support... > > > diff -Nrcpad bison-2.4.1.orig/lib/subpipe.c bison-2.4.1/lib/subpipe.c > *** bison-2.4.1.orig/lib/subpipe.c Mon Nov 3 20:54:12 2008 > --- bison-2.4.1/lib/subpipe.c Thu Jul 9 17:42:33 2009 > *************** > *** 60,65 **** > --- 60,70 ---- > # define vfork fork > #endif > > + #ifdef _WIN32 > + # include <windows.h> > + # include <fcntl.h> > + #endif > + > #include "error.h" > #include "unistd-safer.h" > > *************** init_subpipe (void) > *** 104,109 **** > --- 109,194 ---- > pid_t > create_subpipe (char const * const *argv, int fd[2]) > { > + #if defined(_WIN32) && !defined(__CYGWIN__) > + PROCESS_INFORMATION pi; > + STARTUPINFO si; > + HANDLE hrdStdIn, hwrStdIn, hrdStdOut, hwrStdOut, hwrStdErr; > + char args[32*1024]; > + > + hrdStdIn = hwrStdIn = hrdStdOut = hwrStdOut = hwrStdErr = > INVALID_HANDLE_VALUE; > + do { > + HANDLE hThis = GetCurrentProcess(); > + > + if( 0 == CreatePipe(&hrdStdIn, &hwrStdIn, 0, 0) || > + 0 == DuplicateHandle(hThis, hrdStdIn, hThis, > &hrdStdIn, > + 0, TRUE, > DUPLICATE_CLOSE_SOURCE|DUPLICATE_SAME_ACCESS) || > + 0 == CreatePipe(&hrdStdOut, &hwrStdOut, 0, 0) || > + 0 == DuplicateHandle(hThis, hwrStdOut, hThis, > &hwrStdOut, > + 0, TRUE, > DUPLICATE_CLOSE_SOURCE|DUPLICATE_SAME_ACCESS) || > + 0 == DuplicateHandle(hThis, hwrStdOut, hThis, > &hwrStdErr, > + 0, TRUE, DUPLICATE_SAME_ACCESS) ) > + { > + error(EXIT_FAILURE, GetLastError(), "CreatePipe"); > + } > + > + if( 0 == _access(argv[0], 0) ) > + strcpy(args,argv[0]); > + else { > + if( 0 == SearchPath(0, argv[0], ".exe", _MAX_PATH, > args, 0) ) > + error(EXIT_FAILURE, GetLastError(), > "SearchPath"); > + } > + > + if(1) { > + char** pArgv = argv + 1; > + while( *pArgv ) > + { > + strcat(args, " "); > + if( strchr(*pArgv, ' ') || strchr(*pArgv, > '\t') ) > + { > + strcat(args, "\""); > + strcat(args, *pArgv); > + strcat(args, "\""); > + } else > + strcat(args, *pArgv); > + ++pArgv; > + } > + } > + > + memset(&si, 0, sizeof(si)); > + si.cb = sizeof(si); > + si.dwFlags = STARTF_USESHOWWINDOW | > STARTF_USESTDHANDLES; > + si.wShowWindow = SW_HIDE; > + si.hStdInput = hrdStdIn; > + si.hStdOutput = hwrStdOut; > + si.hStdError = hwrStdErr; > + if( !CreateProcess( > + NULL, //appname > + args, //commandline (currently: > appname + command line) > + NULL, //process security attributes > + NULL, //thread security attributes > + TRUE, //inherit handles > + 0, //creation flags > + NULL, //environment > + NULL, //current directory > + &si, &pi) ) > + { > + error(EXIT_FAILURE, GetLastError(), > "CreateProcess"); > + } > + CloseHandle(hrdStdIn); > + CloseHandle(hwrStdOut); > + CloseHandle(hwrStdErr); > + CloseHandle(pi.hThread); > + CloseHandle(pi.hProcess); > + > + fd[0] = _open_osfhandle((intptr_t)hwrStdIn,_O_TEXT); > + fd[1] = _open_osfhandle((intptr_t)hrdStdOut,_O_TEXT); > + return; > + } while(0); > + CloseHandle(hrdStdIn); CloseHandle(hwrStdIn); > + CloseHandle(hrdStdOut); CloseHandle(hwrStdOut); > + CloseHandle(hwrStdErr); > + return 0; > + #else/*not _WIN32*/ > int pipe_fd[2]; > int child_fd[2]; > pid_t pid; > *************** create_subpipe (char const * const *argv > *** 140,145 **** > --- 225,231 ---- > close (child_fd[0]); > close (child_fd[1]); > return pid; > + #endif > } > > > diff -Nrcpad bison-2.4.1.orig/src/output.c bison-2.4.1/src/output.c > *** bison-2.4.1.orig/src/output.c Wed Nov 19 18:57:30 2008 > --- bison-2.4.1/src/output.c Thu Jul 9 17:44:38 2009 > *************** > *** 40,45 **** > --- 40,68 ---- > #include "symtab.h" > #include "tables.h" > > + #if defined(_WIN32) && !defined(__CYGWIN__) > + extern long __stdcall GetModuleFileNameA(void*, char*, size_t); > + # undef PKGDATADIR > + # define PKGDATADIR win32_PKGDATADIR() > + static const char* win32_PKGDATADIR() > + { > + static char pkgdir[_MAX_PATH] = {0}; > + if( 0 == *pkgdir ) { > + char* slash; > + GetModuleFileNameA(0, pkgdir, sizeof(pkgdir) ); > + slash = strrchr(pkgdir, '\\'); > + if( slash ) *(slash+1) = 0; > + while( (slash = strchr(pkgdir, '\\')) ) > + *slash = '/'; > + strcat(pkgdir, "bison.dir/"); > + } > + return pkgdir; > + } > + > + #undef M4 > + #define M4 "m4.exe" > + #endif > + > > static struct obstack format_obstack; > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Keith M. <kei...@us...> - 2009-11-13 21:35:50
|
On Thursday 12 November 2009 12:07:39 Vasili Burdo wrote: > BTW, I tried to post this patch to bison ML several years ago, the > response was they aren't interested in native Win32 support... I'm not surprised they weren't interested; I would have rejected that patch too! All of the completely unnecessary Microsoft specific cruft you've used, to get to CreatePipe() and CreateProcess(), with all of its ghastly attendant typedef obfuscation, is a real turn off for open source developers, who value portability. If you are porting open source software originally intended for a POSIX host, such Microsoft specific nastiness should be considered as a measure of absolute last resort. In this case, you need none of it; instead: * POSIX's `pipe()' function may be trivially mapped by a simple `#define pipe(pfd) _pipe((pfd), 0, _O_BINARY|_O_NOINHERIT)' * the `fork()' and subsequent `exec??()' sequence, which typically looks something like: if( (child = fork()) == 0 ) { /* some code here, to initialise child I/O context */ exec??( program, arguments ... ); /* code here, to handle failed exec */ } else if( child < 0 ) { /* code here to handle failed fork */ } /* parent code continues here */ should be converted to use the `spawn??()' function with `??' suffix to match that of the original `exec??()' call, something like this: /* code to save parent's I/O context, then modify it to create * that required by the child, goes here */ if( (child = spawn??( _P_NOWAIT, program, arguments ... )) < 0 ) { /* code to handle failed spawn, replacing both fork and exec * failure conditions, goes here */ } /* need code here, to restore parent I/O context to its state * as saved prior to spawn */ /* parent code continues here */ See how minimally that changes the original code? Especially when compared to the ghastly mess you proposed? Such minimally intrusive patches stand a much greater chance of acceptance. -- Regards, Keith. |
From: Vasili B. <vas...@gm...> - 2009-11-16 18:11:13
|
Keith Marshall wrote: > * POSIX's `pipe()' function may be trivially mapped by a simple > `#define pipe(pfd) _pipe((pfd), 0, _O_BINARY|_O_NOINHERIT)' Keith, I'm greatly impressed how deep you feel and understand open source philosophy. But I, a humble programmer, want one basic thing: the program which works. Coming to this task, I see few minor drawbacks in your proposal: 1) pipe() returns FILE* to stdout, whereas we need fds both to stdout and stderr. 2) fork() isn't present on Win32 3) spawn() dont provide pipes to stdout and stderr. Besides these problems, your proposal is plain excellent - it's all philosophic, posixish, and stuff. I'm very sorry I bothered you with my crappy code. It works, and this is its only value. PS. English isn't my native lang, so forgive me for (very probable) errors. Vasili. |
From: Keith M. <kei...@us...> - 2009-11-17 20:28:14
|
On Monday 16 November 2009 18:10:41 Vasili Burdo wrote: > > * POSIX's `pipe()' function may be trivially mapped by a simple > > `#define pipe(pfd) _pipe((pfd), 0, _O_BINARY|_O_NOINHERIT)' > > Keith, I'm greatly impressed how deep you feel and understand open > source philosophy. But I, a humble programmer, want one basic > thing: the program which works. The sarcasm, if it was intended, is surely unwarranted; you complained that your grossly Microsoft centric patch was rejected by an open source project; I offered you an explanation of why that might be. > Coming to this task, I see few minor drawbacks in your proposal: > 1) pipe() returns FILE* to stdout, It does nothing of the sort; it creates an unnamed pipe, and returns a pair of file descriptors, one of which may be used to push data into the pipe, the other to retrieve that data as it emerges from the other end. Neither of these file descriptors is implicitly associated with stdin, stdout, stderr nor any other existing stream. > whereas we need fds both to stdout and stderr. Two separate *output* streams? If you need to separate them, then you would need two pipes, otherwise you have to merge them into a single stream. > 2) fork() isn't present on Win32 No, it isn't; you use spawn() instead. > 3) spawn() dont provide pipes to stdout and stderr. Neither does fork(), (on *nix). Spawn, expressed in a concrete example by way of: child = spawnlp( _P_NOWAIT, "prog", "prog", "arg1", "arg2", NULL ); is pretty much the direct equivalent of *nix's: if( (child = fork()) == 0 ) execlp( "prog", "prog", "arg1", "arg2", NULL ); (which doesn't provide any pipe on *any* stream either). The weakness of spawn() [*], when compared with the fork()...exec() paradigm, is that it affords no opportunity to perform any other action *between* the fork() and the exec(), (which is where *nix apps typically would do the pipeline hook ups), so you have to do that *before* you call spawn(), (which typically requires you to save the parent's I/O descriptors first, then restore them after you've called spawn()). You use dup() to save the parent's streams, while you redirect their original descriptors with dup2(), for use by the child, (just as the *nix app will do); you then use dup2() again, to restore the parent's original descriptors for the redirected stream(s), after you've spawn()ed the child. > Besides these problems, your proposal is plain excellent - it's > all philosophic, posixish, and stuff. I'm very sorry I bothered > you with my crappy code. It works, and this is its only value. I'm sure it does; I don't dispute that. My point was that it is likely to receive a very negative response from the maintainer of a *nix centric project, as was your experience. OTOH, I have had some success in having such patches accepted by GNU projects, when I have presented them in the much less intrusive format I have advocated. [*] Aside from its approximate equivalence to fork()...exec(), there *is* an issue with spawn(): there is a bug in it's implementation, (which is also apparent in Microsoft's implementation of exec()), whereby it does not correctly quote arguments containing white space when eventually handing them off to CreateProcess(); MinGW offers a work around for this bug, in the form of the execwrap library; (GPL2 code, in the UserContributed section of the SF repository). -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-11-18 16:41:51
|
Keith Marshall wrote: > [*] Aside from its approximate equivalence to fork()...exec(), there > *is* an issue with spawn(): there is a bug in it's implementation, > (which is also apparent in Microsoft's implementation of exec()), > whereby it does not correctly quote arguments containing white space > when eventually handing them off to CreateProcess(); MinGW offers a > work around for this bug, in the form of the execwrap library; (GPL2 > code, in the UserContributed section of the SF repository). There's similar argv quoting code in libtool-2.2.7, under the GPLv2 license with the following exception: # As a special exception to the GNU General Public License, # if you distribute this file as part of a program or library that # is built using GNU Libtool, you may include this file under the # same distribution terms that you use for the rest of that program. I took advantage of this exception to incorporate libtool's prepare_spawn() as run2_quote_argv() in the (MIT/X-licensed portion of) the run2 package. -- Chuck |
From: Vincent T. <vt...@un...> - 2009-11-13 22:31:16
|
On Fri, 13 Nov 2009, Keith Marshall wrote: > * POSIX's `pipe()' function may be trivially mapped by a simple > `#define pipe(pfd) _pipe((pfd), 0, _O_BINARY|_O_NOINHERIT)' It could be less simple than you say. Afaik, you can't use _pipe() with select() as the latter uses sockets on Windows and not fd. Vincent Torri |
From: Keith M. <kei...@us...> - 2009-11-17 20:28:27
|
On Friday 13 November 2009 22:30:55 Vincent Torri wrote: > > * POSIX's `pipe()' function may be trivially mapped by a simple > > `#define pipe(pfd) _pipe((pfd), 0, _O_BINARY|_O_NOINHERIT)' > > It could be less simple than you say. Afaik, you can't use _pipe() > with select() as the latter uses sockets on Windows and not fd. AFAIK, the same limitation applies when you use the more Microsoft centric CreatePipe(). _pipe would be seem to be just a wrapper around CreatePipe() anyway; its advantage, to those porting *nix code, is that the original pipe() call in the *nix code doesn't need to be changed, when the above #define is in place. You are correct, that if the original code uses select(), or poll(), to monitor data traffic through the pipe, then the problem becomes more complex, (because MS-Windows can't use these functions with file streams). However, in the majority of cases where pipes are used to communicate between parent and child processes, (typically using redirected stdin or stdout), the paradigm I have described works well. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2009-11-18 19:53:34
|
On Wednesday 18 November 2009 16:41:01 Charles Wilson wrote: > Keith Marshall wrote: > > [*] Aside from its approximate equivalence to fork()...exec(), > > there *is* an issue with spawn(): there is a bug in it's > > implementation, (which is also apparent in Microsoft's > > implementation of exec()), whereby it does not correctly quote > > arguments containing white space when eventually handing them > > off to CreateProcess(); MinGW offers a work around for this bug, > > in the form of the execwrap library; (GPL2 code, in the > > UserContributed section of the SF repository). > > There's similar argv quoting code in libtool-2.2.7, under the > GPLv2 license with the following exception: > > # As a special exception to the GNU General Public License, > # if you distribute this file as part of a program or library that > # is built using GNU Libtool, you may include this file under the > # same distribution terms that you use for the rest of that > program. Which is all fine and dandy, if you are using libtool, or if your project is already using a GPL compatible licence. I originally wrote the code from which libexecwrap.a is derived as part of my porting contribution to GNU troff (groff). It was the culmination of a protracted discussion with Werner Lemberg, (the lead maintainer), and another user who was interested in getting groff to build better with MSVC. As the sole author of the actual code, I guess I could grant a GPL exception in respect of use by projects building with MinGW, and integrate it into libmingwex.a, enabled under a __MINGW_FEATURES__ extension. However, before I do that, as a matter of courtesy I should ask the other contributors to the design discussion if they have any objection, and, since I also assigned copyright to the FSF, I guess I should also clear it with them. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-11-18 21:18:31
|
Keith Marshall wrote: >> # As a special exception to the GNU General Public License, >> # if you distribute this file as part of a program or library that >> # is built using GNU Libtool, you may include this file under the >> # same distribution terms that you use for the rest of that >> program. > > Which is all fine and dandy, if you are using libtool, or if your > project is already using a GPL compatible licence. Sortof. I already discussed this with Ralf W. (who is also not a lawyer, etc etc). But run2 uses libtool and is built using libtool. The components we're discussing here are otherwise MIT/X. Therefore, I'm allowed to distribute, with run2, ltmain.sh under the same distribution terms. That is, MIT/X. Thus, I can pull code out of that copy of ltmain.sh, exploiting its effective MIT/X license, and put it into any other MIT/X source file (which I have done, in run2/lib/launch.c; this is all explained in run2/COPYING). Yes, it's a loophole. Yes, it's probably contrary to the copyleft spirit intended by the application of the GPL to the libtool code itself (nobody really expected a shell script to contain much in the way of compilable C code, so the whole issue of binary-dist requiring src-dist is USUALLY moot for shell scripts). But, this is explicitly allowed by the exception language. Once libtool is relicensed under GPLv3, the libtool team will probably take steps (somehow) to eliminate this loophole -- but that still wouldn't retroactively eliminate the loophole for current versions of ltmain.sh. The point is, that particular function is now part of an MIT/X-licensed file, and can be extracted for use in ANY (MIT/X-compatible) project, whether they use libtool or not. > I originally wrote the code from which libexecwrap.a is derived as > part of my porting contribution to GNU troff (groff). It was the > culmination of a protracted discussion with Werner Lemberg, (the > lead maintainer), and another user who was interested in getting > groff to build better with MSVC. Well, it was actually the fact that libexecwrap was GPLed that sent me off looking for another, independent, non-copyleft implementation, eventually leading me to libtool/ltmain and the exception-language loophole. > As the sole author of the actual Just to clarify, you're talking about libexecwrap, not libtool/ltmain.sh. Bruno Haible (and Ralf W) wrote the libtool version (2008-11-11). As far as I know, the libtool code bears no relation to your libexecwrap code (except, of course, that they both were written to perform the same function: accommodate msvcrt's borked-up spawn/exec). > code, I guess I could grant a GPL exception in respect of use by > projects building with MinGW, and integrate it into libmingwex.a, > enabled under a __MINGW_FEATURES__ extension. However, before I do > that, as a matter of courtesy I should ask the other contributors to > the design discussion if they have any objection, and, since I also > assigned copyright to the FSF, I guess I should also clear it with > them. That's up to you (and the FSF). Even if you just added exception language to the core function, and added it to libmingwex without all the additional, nifty-cool glue wrappers that make spawn et.al. "just work". That is, how about the following implied "contract" ====== Given that spawn etc are basically broken with regards to quoting, mingw provides the following function, under the typical licensing terms of the rest of the mingw runtime and w32api files. This enables you to "fix up" argv[] arrays and properly quote them before calling spawn or exec. However, you must call this fixup function manually, in your own code, for each invocation of spawn or exec. The GPL-licensed libexecwrap package provides automatic wrappers for transparently invoking the quote-fix-up function and the underlying spawn/exec functions, without requiring changes to your client code other than: #including a specific header file and -llinking with a specific library. However, as with all GPL-licensed libraries, doing this will effectively relicense your client code under the GPL, and you will be required to make your own client source code available under its terms. ====== I have no objections to any decision you make in this regard. Do it, don't do it. Whatever. I think it'd be neat if it were available in libmingwex, but again -- that's up to you. -- Chuck |
From: Keith M. <kei...@us...> - 2009-11-19 23:30:06
|
On Wednesday 18 November 2009 21:17:48 Charles Wilson wrote: > > As the sole author of the actual > > Just to clarify, you're talking about libexecwrap, Yes. > not > libtool/ltmain.sh. Bruno Haible (and Ralf W) wrote the libtool > version (2008-11-11). My implementation pre-dated that: groff's ChangeLog records the initial commit (by me) dated 2004-02-21. The attribution is for me and Jeff Conrad; I wrote the code; Jeff reviewed it, and identified any MSVC issues which arose during the development. > As far as I know, the libtool code bears no > relation to your libexecwrap code (except, of course, that they > both were written to perform the same function: accommodate > msvcrt's borked-up spawn/exec). Werner also invited Bruno to comment, at the time; he pointed us to an alternative implementation he was working on for gnulib. As is typical of much of Bruno's code, his was more complex, and seemed unnecessarily so; we opted to stick with my simpler version. > > I guess I could grant a GPL exception in respect of use by > > projects building with MinGW, and integrate it into > > libmingwex.a, enabled under a __MINGW_FEATURES__ extension. > > However, before I do that, as a matter of courtesy I should ask > > the other contributors to the design discussion if they have any > > objection, and, since I also assigned copyright to the FSF, I > > guess I should also clear it with them. > > That's up to you (and the FSF). Even if you just added exception > language to the core function, and added it to libmingwex without > all the additional, nifty-cool glue wrappers that make spawn > et.al. "just work". Well, I wrote the nifty glue wrappers later, and exclusively for libexecwrap; they don't appear in the groff code, (or in any other code I've contributed to FSF projects). Thus, these would be easy for me to simply relicense for use in libmingwex; it's the core function, which performs the argument quoting, that represents the only stumbling block, (requiring a GPL exception). > That is, how about the following implied "contract" I think I'd prefer to get agreement from Werner and Jeff before I pursue this at all, and the seek advice from FSF on the wording of an appropriate exception. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2009-11-19 23:49:43
|
On Thursday 19 November 2009 23:29:47 Keith Marshall wrote: > Well, I wrote the nifty glue wrappers later, and exclusively for > libexecwrap; they don't appear in the groff code, To clarify: there is a simple wrapper for spawnvp() in the groff code. The mechanism I adopted for generalising to wrap all other members of the spawn() and exec() families was a later development exclusive to libexecwap. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2009-11-20 00:48:49
|
Keith Marshall wrote: > I think I'd prefer to get agreement from Werner and Jeff before I > pursue this at all, and the seek advice from FSF on the wording of > an appropriate exception. Ack. I'll be over here, in the cheering section, regardless...you guys do whatever you think is best. -- Chuck |
From: Vasili B. <vas...@gm...> - 2009-11-19 13:06:55
|
Keith Marshall wrote: > you complained that your grossly Microsoft centric patch was rejected by an open source project; Nobody complains. I volunteered a patch. They decided not to use it. All even. I maintain it for my own needs starting from bison-2.0 . I payed my debt to bison project by offering it. And I don't care they refused to accept it. > I offered you an explanation of why that might be. "Explanation" which includes word similar to "cruft" needs another name... >> Coming to this task, I see few minor drawbacks in your proposal: >> 1) pipe() returns FILE* to stdout, > It does nothing of the sort; Yes, indeed. Sorry. I mistook it for fdopen() which I was considering to use, but didn't find reliable (and documented) way to get fd from FILE* and close that FILE* while keeping fd open. Because fdopen doesn't provide fd to stderr anyways, I picked Win32 way. >[snip] The idea to use buggy POSIX layer of MSVCRT and maintain it usable throughout all (present and future) versions remind me rectal dentistry. I agree that Win32 implementation don't fit into POSIX-sh bison, but alternative is worse. Bottom line. I'm not going to continue this discussion and/or modify my patch. I will maintain my patch and offer it upon request. I see no reason to persuade bison maintainers to use it. I offered it once. That's enough. |
From: Tor L. <tm...@ik...> - 2009-11-19 13:22:28
|
> didn't find reliable (and documented) way to get fd from FILE* and close that > FILE* while keeping fd open. Umm, fd = dup(fileno(stream)); fclose(stream); ? Not sure if this is what you are looking for, but as far as I know fileno() and dup() work in the Microsoft C library essentially like they do on Unix. > Because fdopen doesn't provide fd to stderr > anyways, fdopen() doesn't "provide" fds, but do you mean fdopen(2, "w") ? --tml |