Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def-translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). -- http://rrt.sc3d.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def-translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 7:53 AM, Steve Holden wrote: On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etexpdfetex language.def -translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. It struck me that this remark might be ambiguous, or even be regarded as offensive by some. My intention was to highlight the fact that issues will (eventually) be re-raised thanks to the phenomenal group memory of this list. But of course the issue might have had attention (or at least been resolved as wontfix with appropriate discussion) in an issue tracker. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 08/20/2010 06:00 AM, Steve Holden wrote: My intention was to highlight the fact that issues will (eventually) be re-raised thanks to the phenomenal group memory of this list. But of course the issue might have had attention (or at least been resolved as wontfix with appropriate discussion) in an issue tracker. Or, more likely, sat for four years with no change in status, because the same person who hasn't had time to fix the tex package also hasn't had time to visit a tracker web page. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 9:22 AM, Eric Blake wrote: On 08/20/2010 06:00 AM, Steve Holden wrote: My intention was to highlight the fact that issues will (eventually) be re-raised thanks to the phenomenal group memory of this list. But of course the issue might have had attention (or at least been resolved as wontfix with appropriate discussion) in an issue tracker. Or, more likely, sat for four years with no change in status, because the same person who hasn't had time to fix the tex package also hasn't had time to visit a tracker web page. Yes, ultimately it's all down to the availability of effort. We have similar problems in the Python world (where we use roundup). Though a small team has recently started to address the question of stalled issues, there just isn't enough effort to get to everything that comes in and still keep the language moving forward. I'd like to take this opportunity to say how much I personally appreciate the availability of Cygwin - I use it daily, and it makes the computing experience on Windows far more bearable and productive than it otherwise would be. I'll happily overlook the occasional crabby reply to a thoughtless comment, given the amazing work that the team collectively produces. regards Steve -- Steve HoldenChairman, Python Software Foundation The Python Community Conference http://python.org/psf/ Watch PyCon on video now! http://pycon.blip.tv/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Fri, Aug 20, 2010 at 08:00:14AM -0400, Steve Holden wrote: On 8/20/2010 7:53 AM, Steve Holden wrote: On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def -translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. It struck me that this remark might be ambiguous, or even be regarded as offensive by some. I found it tedious actually, and wondered if you were going to now start jumping up and down in every message where it seems remotely possible that an issue tracker was the solution to a problem. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Fri, Aug 20, 2010 at 10:14:29AM -0400, Steve Holden wrote: I'd like to take this opportunity to say how much I personally appreciate the availability of Cygwin - I use it daily, and it makes the computing experience on Windows far more bearable and productive than it otherwise would be. I'll happily overlook the occasional crabby reply to a thoughtless comment, given the amazing work that the team collectively produces. I just want to assure everyone that I put a lot of thought into my crabby replies. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 11:43 AM, Christopher Faylor wrote: On Fri, Aug 20, 2010 at 08:00:14AM -0400, Steve Holden wrote: On 8/20/2010 7:53 AM, Steve Holden wrote: On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def -translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. It struck me that this remark might be ambiguous, or even be regarded as offensive by some. I found it tedious actually, and wondered if you were going to now start jumping up and down in every message where it seems remotely possible that an issue tracker was the solution to a problem. Oh, no. I think the issue has been adequately exercised already, and I have no skin in that particular game. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
the script needs to initialize IFS Ok, I put in the initialization. Thanks for the report explanation. - I don't know about the NULL_DEVICE and the path_sep setting changes I don't either, I just do what I'm told :). Whatever the Cygwin folks say should be done in the Cygwin part of the code is fine, of course. I'll attach the current system.h from Texinfo CVS. Please let me know if changes should be made. Thanks, Karl system.h Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Sat, May 27, 2006 at 02:09:58PM -0500, Karl Berry wrote: Content-Description: message body text the script needs to initialize IFS Ok, I put in the initialization. Thanks for the report explanation. - I don't know about the NULL_DEVICE and the path_sep setting changes I don't either, I just do what I'm told :). Whatever the Cygwin folks say should be done in the Cygwin part of the code is fine, of course. I'll attach the current system.h from Texinfo CVS. Please let me know if changes should be made. Cygwin's NULL_DEVICE is the same as linux or any other unix-like system. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
I forgot to cc bug-texinfo on this, so let me do that and expand on things a little. On Sun, May 28, 2006 at 11:43:19AM -0400, Christopher Faylor wrote: On Sat, May 27, 2006 at 02:09:58PM -0500, Karl Berry wrote: Content-Description: message body text the script needs to initialize IFS Ok, I put in the initialization. Thanks for the report explanation. - I don't know about the NULL_DEVICE and the path_sep setting changes I don't either, I just do what I'm told :). Whatever the Cygwin folks say should be done in the Cygwin part of the code is fine, of course. I'll attach the current system.h from Texinfo CVS. Please let me know if changes should be made. Cygwin's NULL_DEVICE is the same as linux or any other unix-like system. As is the path separator. i.e., the patch that Ralf Wildenhues previously sent out is correct (which shouldn't be too surprising since it came from the texinfo release). There should be no accommodations made for Windows when running under Cygwin. I understand that parts of the previously posted patch (which is incorporated in to Cygwin's release of texinfo) may be too draconian for a native Windows version of texinfo out there but I wasn't really interested in getting things working for native Windows. The fact that a COMSPEC environment variable exists doesn't have any bearing in a Cygwin environment. And, Cygwin wants to use /dev/null, not NUL. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Sun, May 28, 2006 at 12:35:53PM -0400, Christopher Faylor wrote: i.e., the patch that Ralf Wildenhues previously sent out is correct (which shouldn't be too surprising since it came from the texinfo release). ^ cygwin (I bet I'll regret not making that clear) cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
Date: Sun, 28 May 2006 12:13:03 -0500 From: [EMAIL PROTECTED] (Karl Berry) Cc: [EMAIL PROTECTED] Ralf's texi2dvi changes are clearly not generally applicable. E.g., Eli has spent a lot of time making Texinfo (and everything else) work under DJGPP. I can't just blow that away. The suggested change will blow away not only the DJGPP support, but also the native Windows (a.k.a. MinGW) build support. We should try to support Cygwin without breaking other ports. If there's a way to detect when it's running under Cygwin, then the changes could be conditionalized as needed, I presume. I think CYGWIN is such a variable, but Chris is a better person to tell the details. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Sun, May 28, 2006 at 12:13:03PM -0500, Karl Berry wrote: On Sun, May 28, 2006 at 12:35:53PM -0400, Christopher Faylor wrote: i.e., the patch that Ralf Wildenhues previously sent out is correct (which shouldn't be too surprising since it came from the texinfo release). There should be no accommodations made for Windows when running under Cygwin. I understand that parts of the previously posted patch (which is incorporated in to Cygwin's release of texinfo) may be too draconian for a native Windows version of texinfo out there but I wasn't really interested in getting things working for native Windows. The fact that a COMSPEC environment variable exists doesn't have any bearing in a Cygwin environment. And, Cygwin wants to use /dev/null, not NUL. Ok, I applied the change to system.h, so that NULL_DEVICE will be /dev/null under Cygwin. Makes sense. Ralf's texi2dvi changes are clearly not generally applicable. This wasn't Ralf's patch. It was the patch that I use in the cygwin release of texinfo. E.g., Eli has spent a lot of time making Texinfo (and everything else) work under DJGPP. I can't just blow that away. That's why I said it was too draconian in the part of my email which you snipped (and which I put back above). If there's a way to detect when it's running under Cygwin, then the changes could be conditionalized as needed, I presume. There is a consistent theme here. What path separator do you use? The same as Linux. What null device do you use? The same as Linux. How would you detect if you were running under cygwin? Similarly to Linux, one technique would be to use uname -s. I'll attach the current CVS texi2dvi (there have been tons of changes) in case you or Ralf someone feels like working on this. When I release my version of texinfo, I'm happy to continue to just nuke all of the COMSPEC/Comspec/break-the-path-apart-stuff and just use which. IMO, this is one of those cases where it doesn't pay to be too clever. You already know what target the script is going to be running on so shouldn't it be tailored to the target in a configure step rather than checking each time? But then I seem to vaguely recall this being discussed at one point and maybe this has already been endlessly debated. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
i.e., the patch that Ralf Wildenhues previously sent out is correct Ok, I applied the change to system.h, so that NULL_DEVICE will be /dev/null under Cygwin. Makes sense. Ralf's texi2dvi changes are clearly not generally applicable. E.g., Eli has spent a lot of time making Texinfo (and everything else) work under DJGPP. I can't just blow that away. If there's a way to detect when it's running under Cygwin, then the changes could be conditionalized as needed, I presume. I'll attach the current CVS texi2dvi (there have been tons of changes) in case you or Ralf someone feels like working on this. And the texindex.c problem has already been fixed in another way. Thanks, Karl texi2dvi Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
Hi Karl, Christopher,
* Karl Berry wrote on Sat, May 27, 2006 at 01:21:16AM CEST:
[Excluding cygwin, I doubt they care about this part.]
Oh yes they will care especially about this part. ;-)
$ texindex ./main.au ./main.cp ./main.pg ./main.sb
Segmentation fault (core dumped)
Regrettably, with both the texindex in the released 4.8, and the
texindex from current CVS, I get no seg fault on GNU/Linux (x86).
That's because the bug isn't in GNU texinfo-4.8, but in the Cygwin
package texinfo-4.8-2.
* Christopher Faylor wrote on Fri, May 26, 2006 at 07:28:13AM CEST:
That's apparently a call to mktemp, although I can't tell what's causing
the problem.
Setting the CYGWIN environment variable to error_start:gdb might help
with finding what the argument to mktemp is.
Thanks for those hints. It turns out to be mktemp.
Running under gdb (or with CYGWIN set accordingly) doesn't help much if
you don't have source and debugging symbols are not compiled in. So I
learned that Cygwin allows to install source packages, rebuilt
texinfo-4.8-2, and also built the pristine texinfo-4.8 from gnu.org.
The latter worked fine, the former crashes. The diff between both is
shown at the end of this message.
The obvious bug is
+ tempbase = mktemp (txidxXX);
as mktemp changes the string it gets a pointer to, but here it gets a
pointer to potentially read-only memory. And recent GCCs do put this in
the read-only section of the binary. This can be rewritten to work like
this:
{
static char s[] = txidxXX;
tempbase = mktemp (s);
}
but since the original code works fine on Cygwin, I don't see why the
change shouldn't just be dropped (in case you haven't noticed: texinfo
comes with a mkstemp replacement function, and the configure script will
cause to use that if the system doesn't have one; but also Cygwin
apparently *has* mkstemp -- at least the configure test for it succeeds
-- even though there seems to be no manpage for it).
While at it, here's a chance to reconcile the remaining differences
between the upstream and the Cygwin version:
- CVS texinfo has the findprog function in texi2dvi fixed right (i.e.,
by using $IFS for splitting), but the script needs to initialize IFS
to spacetabnewline at the beginning -- see here for why:
http://lists.gnu.org/archive/html/automake-patches/2006-05/msg8.html
- I don't know about the NULL_DEVICE and the path_sep setting changes
-- you need to hash that out yourself. (For path_sep, you could take
a look at Autoconf's internal _AS_PATH_SEPARATOR_PREPARE macro.
What's wrong with reusing its result, stored in PATH_SEPARATOR?)
Cheers,
Ralf
--- texinfo-4.8/lib/system.h2004-04-26 14:56:57.0 +0100
+++ texinfo-4.8-2/lib/system.h 2006-04-30 03:38:39.00100 +0100
@@ -219,6 +219,8 @@
# ifdef __CYGWIN__
# define DEFAULT_TMPDIR /tmp/
# define PATH_SEP :
+# undef NULL_DEVICE
+# define NULL_DEVICE /dev/null
# else /* O_BINARY !__CYGWIN__ */
# define DEFAULT_TMPDIR c:/
# define PATH_SEP ;
--- texinfo-4.8/util/texi2dvi 2004-12-31 19:03:05.0 +0100
+++ texinfo-4.8-2/util/texi2dvi 2005-04-12 02:47:12.00100 +0100
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/bash
# texi2dvi --- produce DVI (or PDF) files from Texinfo (or LaTeX) sources.
# $Id: texi2dvi,v 1.34 2004/12/01 18:35:36 karl Exp $
#
@@ -101,13 +101,7 @@
orig_pwd=`pwd`
-# Systems which define $COMSPEC or $ComSpec use semicolons to separate
-# directories in TEXINPUTS.
-if test -n $COMSPEC$ComSpec; then
- path_sep=;
-else
- path_sep=:
-fi
+path_sep=:
# Pacify verbose cds.
CDPATH=${ZSH_VERSION+.}$path_sep
@@ -118,14 +112,8 @@
# return true if program $1 is somewhere in PATH, else false.
#
findprog () {
- foundprog=false
- for dir in `echo $PATH | tr $path_sep `; do
-if test -x $dir/$1; then # does anyone still need test -f?
- foundprog=true
- break
-fi
- done
- $foundprog
+ /usr/bin/which $1 /dev/null 21
+ return $?
}
# Report an error and exit with failure.
--- texinfo-4.8/util/texindex.c 2004-04-11 18:56:47.0 +0100
+++ texinfo-4.8-2/util/texindex.c 2005-10-07 15:43:50.00100 +0100
@@ -99,6 +99,9 @@
/* Directory to use for temporary files. On Unix, it ends with a slash. */
char *tempdir;
+/* Basename for temp files inside of tempdir. */
+char *tempbase;
+
/* Number of last temporary file. */
int tempcount;
@@ -190,6 +193,11 @@
decode_command (argc, argv);
+ /* XXX mkstemp not appropriate, as we need to have somewhat predictable
+ * names. But race condition was fixed, see maketempname.
+ */
+ tempbase = mktemp (txidxXX);
+
/* Process input files completely, one by one. */
for (i = 0; i num_infiles; i++)
@@ -389,21 +397,21 @@
static char *
maketempname (int count)
{
- static char *tempbase = NULL;
char tempsuffix[10];
-
- if (!tempbase)
-{
- int fd;
- tempbase = concat (tempdir, txidxXX);
-
- fd =
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Sat, May 27, 2006 at 10:05:20AM +0200, Ralf Wildenhues wrote: Hi Karl, Christopher, * Karl Berry wrote on Sat, May 27, 2006 at 01:21:16AM CEST: [Excluding cygwin, I doubt they care about this part.] Oh yes they will care especially about this part. ;-) $ texindex ./main.au ./main.cp ./main.pg ./main.sb Segmentation fault (core dumped) Regrettably, with both the texindex in the released 4.8, and the texindex from current CVS, I get no seg fault on GNU/Linux (x86). That's because the bug isn't in GNU texinfo-4.8, but in the Cygwin package texinfo-4.8-2. * Christopher Faylor wrote on Fri, May 26, 2006 at 07:28:13AM CEST: That's apparently a call to mktemp, although I can't tell what's causing the problem. Setting the CYGWIN environment variable to error_start:gdb might help with finding what the argument to mktemp is. Thanks for those hints. It turns out to be mktemp. Running under gdb (or with CYGWIN set accordingly) doesn't help much if you don't have source and debugging symbols are not compiled in. So I learned that Cygwin allows to install source packages, rebuilt texinfo-4.8-2, and also built the pristine texinfo-4.8 from gnu.org. The latter worked fine, the former crashes. The diff between both is shown at the end of this message. Thanks very much for looking into it. I released a new version of texinfo last night. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex [attn texinfo maintainer]
cgf wrote: 0022FF88 61005EB3 (, , , ) That's apparently a call to mktemp, although I can't tell what's causing the problem. Well, looking at the source to the cygwin distribution of texinfo, it is pretty obvious: $ diff -u texindex.c.orig texindex.c --- texindex.c.orig 2004-04-11 11:56:47.00100 -0600 +++ texindex.c 2005-10-07 08:43:50.00100 -0600 @@ -99,6 +99,9 @@ /* Directory to use for temporary files. On Unix, it ends with a slash. */ char *tempdir; +/* Basename for temp files inside of tempdir. */ +char *tempbase; + /* Number of last temporary file. */ int tempcount; @@ -190,6 +193,11 @@ decode_command (argc, argv); + /* XXX mkstemp not appropriate, as we need to have somewhat predictable + * names. But race condition was fixed, see maketempname. + */ + tempbase = mktemp (txidxXX); + ... OOPS The texinfo maintainer, in their modifications to upstream texindex, is passing a READ-ONLY string to mktemp, and is deserving of their crash (although cygwin could perhaps handle it more gracefully, perhaps by returning NULL on a fault so that at least the stack trace is not in the middle of cygwin1.dll). But if you are going to go to the effort of modifications, use mkstemp instead (mktemp is insecure, after all). I would further argue that maketempname should use the O_BINARY flag to open(), unless texindex can handle text mounts gracefully. Can we get a new texinfo release soon with this fixed? -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex [attn texinfo maintainer]
On Fri, May 26, 2006 at 09:33:12PM +, Eric Blake wrote: cgf wrote: 0022FF88 61005EB3 (, , , ) That's apparently a call to mktemp, although I can't tell what's causing the problem. Well, looking at the source to the cygwin distribution of texinfo, it is pretty obvious: $ diff -u texindex.c.orig texindex.c --- texindex.c.orig 2004-04-11 11:56:47.00100 -0600 +++ texindex.c 2005-10-07 08:43:50.00100 -0600 @@ -99,6 +99,9 @@ /* Directory to use for temporary files. On Unix, it ends with a slash. */ char *tempdir; +/* Basename for temp files inside of tempdir. */ +char *tempbase; + /* Number of last temporary file. */ int tempcount; @@ -190,6 +193,11 @@ decode_command (argc, argv); + /* XXX mkstemp not appropriate, as we need to have somewhat predictable + * names. But race condition was fixed, see maketempname. + */ + tempbase = mktemp (txidxXX); + ... OOPS Calm down, please. The texinfo maintainer, in their modifications to upstream texindex, is passing a READ-ONLY string to mktemp, and is deserving of their crash (although cygwin could perhaps handle it more gracefully, perhaps by returning NULL on a fault so that at least the stack trace is not in the middle of cygwin1.dll). But if you are going to go to the effort of modifications, use mkstemp instead (mktemp is insecure, after all). I would further argue that maketempname should use the O_BINARY flag to open(), unless texindex can handle text mounts gracefully. Can we get a new texinfo release soon with this fixed? This patch is actually not mine. I don't remember exactly where it came from, but google shows a similar patch circulating in a couple of distributions. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
This line in fmtutil.cnf indicates the problem: etexpdfetex language.def-translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. I suspect you could also work around this Cygwin configuration bug by setting TEX=tex before running texi2dvi. HTH, karl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
Hi Karl,
* Karl Berry wrote on Fri, May 26, 2006 at 12:04:15AM CEST:
This line in fmtutil.cnf indicates the problem:
etex pdfetex language.def-translate-file=cp227.tcx
*etex.ini
Either (1) the second word should be changed to etex, or
(2) it should be arranged for etex in invoke pdfetex instead of etex.
E.g., make etex a link to pdfetex, instead of its own binary.
I suspect you could also work around this Cygwin configuration bug by
setting TEX=tex before running texi2dvi.
Bingo, thanks for the analysis! First, setting TEX=tex solves the
issue. Then I tried changing above line. That worked after removing
the ~/.texmf/var/web2c/etex.fmt file from previous tests. I did not try
making etex a link to pdfetex.
So now the Automake tests are looking much better: I'm down to one
failure related to this: txinfo18.test quits with a segmentation fault
of texindex, called by texi2dvi.
Attached are the verbose output of the test, the output of
sh -x texi2dvi --pdf --batch ../main.texi
and a script showing the stack dump of texindex as well as the source
files.
Cheers,
Ralf
make defs aclocal-1.9a automake-1.9a
make[1]: Entering directory `/home/ralf/am/build/tests'
make[1]: `defs' is up to date.
make[1]: `aclocal-1.9a' is up to date.
make[1]: `automake-1.9a' is up to date.
make[1]: Leaving directory `/home/ralf/am/build/tests'
make check-TESTS
make[1]: Entering directory `/home/ralf/am/build/tests'
/home/ralf/am/build/tests:/home/ralf/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/usr/lib/lapack
txinfo18: running makeinfo --version
makeinfo (GNU texinfo) 4.8
Copyright (C) 2004 Free Software Foundation, Inc.
There is NO warranty. You may redistribute this software
under the terms of the GNU General Public License.
For more information about these matters, see the files named COPYING.
=== Running test ../../automake/tests/txinfo18.test
++ pwd
/home/ralf/am/build/tests/testSubDir
+ set -e
+ echo AC_OUTPUT
+ cat
+ cat
+ cat
+ aclocal-1.9a -Werror
+ automake-1.9a --foreign -Werror -Wall --add-missing
Makefile.am:1: installing `./texinfo.tex'
+ autoconf
+ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
configure: creating ./config.status
config.status: creating Makefile
+ make distcheck
{ test ! -d txinfo18-1.0 || { find txinfo18-1.0 -type d ! -perm -200 -exec
chmod u+w {} ';' rm -fr txinfo18-1.0; }; }
test -d txinfo18-1.0 || mkdir txinfo18-1.0
make \
top_distdir=txinfo18-1.0 distdir=txinfo18-1.0 \
dist-info
make[1]: Entering directory `/home/ralf/am/build/tests/testSubDir'
restore=: backupdir=.am$$ \
am__cwd=`pwd` cd . \
rm -rf $backupdir mkdir $backupdir \
if (/bin/sh /home/ralf/am/build/tests/testSubDir/missing --run makeinfo
--version) /dev/null 21; then \
for f in main.info main.info-[0-9] main.info-[0-9][0-9] main.i[0-9]
main.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi \
cd $am__cwd; \
if /bin/sh /home/ralf/am/build/tests/testSubDir/missing --run makeinfo -I . \
-o main.info main.texi; \
then \
rc=0; \
cd .; \
else \
rc=$?; \
cd . \
$restore $backupdir/* `echo ./main.info | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
make[1]: Leaving directory `/home/ralf/am/build/tests/testSubDir'
find txinfo18-1.0 -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec /bin/sh
/home/ralf/am/build/tests/testSubDir/install-sh -c -m a+r {} {} \; \
|| chmod -R a+r txinfo18-1.0
tardir=txinfo18-1.0 /bin/sh /home/ralf/am/build/tests/testSubDir/missing
--run tar chof - $tardir | GZIP=--best gzip -c txinfo18-1.0.tar.gz
{ test ! -d txinfo18-1.0 || { find txinfo18-1.0 -type d ! -perm -200 -exec
chmod u+w {} ';' rm -fr txinfo18-1.0; }; }
case 'txinfo18-1.0.tar.gz' in \
*.tar.gz*) \
GZIP=--best gunzip -c txinfo18-1.0.tar.gz | /bin/sh
/home/ralf/am/build/tests/testSubDir/missing --run tar xf - ;;\
*.tar.bz2*) \
bunzip2 -c txinfo18-1.0.tar.bz2 | /bin/sh
/home/ralf/am/build/tests/testSubDir/missing --run tar xf - ;;\
*.tar.Z*) \
uncompress -c txinfo18-1.0.tar.Z | /bin/sh
/home/ralf/am/build/tests/testSubDir/missing --run tar xf - ;;\
*.shar.gz*) \
GZIP=--best gunzip -c txinfo18-1.0.shar.gz | unshar ;;\
*.zip*) \
unzip txinfo18-1.0.zip ;;\
esac
chmod -R a-w txinfo18-1.0; chmod a+w txinfo18-1.0
mkdir txinfo18-1.0/_build
mkdir txinfo18-1.0/_inst
chmod a-w txinfo18-1.0
dc_install_base=`CDPATH=${ZSH_VERSION+.}: cd txinfo18-1.0/_inst pwd |
sed -e 's,^[^:\\/]:[\\/],/,'` \
dc_destdir=${TMPDIR-/tmp}/am-dc-$$/ \
cd txinfo18-1.0/_build \
../configure --srcdir=.. --prefix=$dc_install_base \
\
make \
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Fri, May 26, 2006 at 06:46:21AM +0200, Ralf Wildenhues wrote: $ cat texindex.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=6105440C eax=004A ebx=0003 ecx=0013 edx=02B9E8A9 esi=00405457 edi=0040544D ebp=0022EE08 esp=0022ED60 program=C:\cygwin\bin\texindex.exe, pid 296, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022EE08 6105440C (00460210, , 0022EEC8, 6108DD7F) 0022EE18 61054685 (0040544D, 6115E684, , 00403229) 0022EEC8 6108DD7F (0005, 6115E684, 00460090, 77DADB0D) 0022EF78 61005BC8 (0022EFD0, , 0002, ) 0022FF88 61005EB3 (, , , ) That's apparently a call to mktemp, although I can't tell what's causing the problem. Setting the CYGWIN environment variable to error_start:gdb might help with finding what the argument to mktemp is. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
Hi Dave, * Dave Korn wrote on Tue, May 23, 2006 at 03:41:51PM CEST: On 23 May 2006 13:13, Ralf Wildenhues wrote: [ As per cygwin-L tradition, I am replying only to the lists; Ralf, if you see this and Karl does not, please feel free to forward it. ] I'm sure Karl reads bug-texinfo; he may just be busy with more important issues ATM. And I guess there was some moderation latency for bug-automake. I believe it's a Cygwin problem and/or TeX installation problem on the particular machine. In essence, texi2dvi is doing this: echo '\input texinfo @bye' txiversion.tex tex txiversion.tex The error message from TeX means that the binary (tex, which was hardwired) being run is trying to load a .fmt that was written by something else (etex). It has nothing to do with the contents of the file. Ok, you got me curious. How does TeX know what application wrote the file if it's not to do with the contents of that file? I can't answer this. However, I've observed problems with cygwin's web2c/... files before, the perms can get messed up somehow and need chowning; they can end up owned by 'None', which means that everyone gets the O (out of UGO) perms, which in a lot of cases are '---', ie. access for user and group only. See http://www.cygwin.com/ml/cygwin/2004-03/msg00454.html for more; I don't know if this is the cause of your problem but I guess it's worth checking the perms on the relevant machine. Well, that would have been nice if it were the cause of the problem. Alas, for me it isn't: I'm both the only user and the administrator and installer of my Cygwin installation, which exists solely to make sure some supposed-to-be portable software continues to run there as well. Making all files and directories below /var/lib/texmf and /usr/share/texmf owned, readable, and writable by the right users and groups did not help one bit. Removing etex.fmt and rerunning $ texi2dvi textutils.texi manually led to this output, pasted below, and still no DVI. Although still PDF builds fine. If I'm to try something different, please bear in mind that, to date, I've been blissfully ignorant of how TeX installations work, mostly because they've always worked for me. Cheers, and thanks for your help, Ralf This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4) file:line:error style messages enabled. %-line parsing enabled. ---! /home/ralf/.texmf/var/web2c/etex.fmt was written by pdfetex (Fatal format file error; I'm stymied) kpathsea: Running mktexfmt etex.fmt fmtutil: running `pdfetex -ini -jobname=etex -progname=etex -translate-file=cp 227.tcx *etex.ini' ... This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (INITEX) file:line:error style messages enabled. %-line parsing enabled. (/usr/share/texmf/web2c/cp227.tcx) entering extended mode (/usr/share/texmf/tex/plain/config/etex.ini (/usr/share/texmf/tex/generic/config/pdftexconfig.tex) (/usr/share/texmf/tex/plain/etex/etex.src (/usr/share/texmf/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texmf/tex/generic/hyphen/hyphen.tex [skipping from \patterns to end-of-file...])) (/usr/share/texmf/tex/plain/etex/etexdefs.lib Skipping module grouptypes; Loading module interactionmodes; Skipping module nodetypes; Skipping module iftypes;) (/usr/share/texmf/tex/plain/config/language.def (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)) Augmenting the Plain TeX definitions: \tracingall; Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone, register allocation; extended register allocation; Recycling: \addlanguage, [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Retaining: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]@@d, [EMAIL PROTECTED]@ad, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], \eTeX, \etexhdrchk, \etexstatus, \module, \uselanguage, [EMAIL PROTECTED], [EMAIL PROTECTED],) ) Beginning to dump on file etex.fmt (format=etex 2006.5.24) 2658 strings of total length 38086 7953 memory locations dumped; current usage is 1977289 1176 multiletter control sequences \font\nullfont=nullfont \font\tenrm=cmr10 \font\preloaded=cmr9 \font\preloaded=cmr8 \font\sevenrm=cmr7 \font\preloaded=cmr6 \font\fiverm=cmr5 \font\teni=cmmi10 \font\preloaded=cmmi9 \font\preloaded=cmmi8 \font\seveni=cmmi7 \font\preloaded=cmmi6 \font\fivei=cmmi5 \font\tensy=cmsy10 \font\preloaded=cmsy9 \font\preloaded=cmsy8
RE: Cygwin: texi2dvi stumbles over texinfo.tex (was: failed checks for automake 1.9.6)
Ok, you got me curious. How does TeX know what application wrote the file if it's not to do with the contents of that file? Sorry, I was referring to the one-line source file \input texinfo @bye As for the .fmt file, yes, it surely records whether tex, etex, pdfetex, etc., was used to generate it. Hence the error. Ralf, what is the output if you run tex \\end from the command line? Also etex \\end and pdfetex \\end This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4) This shows that texi2dvi is invoking etex. This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (INITEX) This shows that mktexfmt is invoking pdfetex to build etex.fmt. This mismatch is causing the error. This is controlled by the file fmtutil.cnf. What does that file look like in your installation? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
Hi Karl, * Karl Berry wrote on Wed, May 24, 2006 at 10:03:39PM CEST: Ralf, what is the output if you run tex \\end etex \\end pdfetex \\end See typescript, attached. This shows that texi2dvi is invoking etex. This shows that mktexfmt is invoking pdfetex to build etex.fmt. This mismatch is causing the error. This is controlled by the file fmtutil.cnf. What does that file look like in your installation? Also attached. In Cygwin's /usr/share/texmf/web2c, there are *.cygwin-dist and *.cygwin-orig copies of fmtutil.cnf, mktex.cnf, and texmf.cnf. The respective copies are all identical, though. Cheers, Ralf Script started on Thu May 25 07:21:22 2006 $ tex \\end This is TeXk, Version 3.141592 (Web2C 7.5.4) file:line:error style messages enabled. %-line parsing enabled. No pages of output. Transcript written on texput.log. $ etex \\end This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4) file:line:error style messages enabled. %-line parsing enabled. ---! /home/ralf/.texmf/var/web2c/etex.fmt was written by pdfetex (Fatal format file error; I'm stymied) $ pdfetex \\end This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) file:line:error style messages enabled. %-line parsing enabled. entering extended mode No pages of output. Transcript written on texput.log. $ file ~/.texmf/var/web2c/etex.fmt /home/ralf/.texmf/var/web2c/etex.fmt: data $ mv ~/.texmf/var/web2c/etex.fmt ~/.texmf/var/web2c/etex.fmt-broken $ etex \\end This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4) file:line:error style messages enabled. %-line parsing enabled. kpathsea: Running mktexfmt etex.fmt fmtutil: running `pdfetex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx *etex.ini' ... This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (INITEX) file:line:error style messages enabled. %-line parsing enabled. (/usr/share/texmf/web2c/cp227.tcx) entering extended mode (/usr/share/texmf/tex/plain/config/etex.ini (/usr/share/texmf/tex/generic/config/pdftexconfig.tex) (/usr/share/texmf/tex/plain/etex/etex.src (/usr/share/texmf/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texmf/tex/generic/hyphen/hyphen.tex [skipping from \patterns to end-of-file...])) (/usr/share/texmf/tex/plain/etex/etexdefs.lib Skipping module grouptypes; Loading module interactionmodes; Skipping module nodetypes; Skipping module iftypes;) (/usr/share/texmf/tex/plain/config/language.def (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)) Augmenting the Plain TeX definitions: \tracingall; Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone, register allocation; extended register allocation; Recycling: \addlanguage, [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Retaining: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]@@d, [EMAIL PROTECTED]@ad, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], \eTeX, \etexhdrchk, \etexstatus, \module, \uselanguage, [EMAIL PROTECTED], [EMAIL PROTECTED],) ) Beginning to dump on file etex.fmt (format=etex 2006.5.25) 2658 strings of total length 38086 7953 memory locations dumped; current usage is 1977289 1176 multiletter control sequences \font\nullfont=nullfont \font\tenrm=cmr10 \font\preloaded=cmr9 \font\preloaded=cmr8 \font\sevenrm=cmr7 \font\preloaded=cmr6 \font\fiverm=cmr5 \font\teni=cmmi10 \font\preloaded=cmmi9 \font\preloaded=cmmi8 \font\seveni=cmmi7 \font\preloaded=cmmi6 \font\fivei=cmmi5 \font\tensy=cmsy10 \font\preloaded=cmsy9 \font\preloaded=cmsy8 \font\sevensy=cmsy7 \font\preloaded=cmsy6 \font\fivesy=cmsy5 \font\tenex=cmex10 \font\preloaded=cmss10 \font\preloaded=cmssq8 \font\preloaded=cmssi10 \font\preloaded=cmssqi8 \font\tenbf=cmbx10 \font\preloaded=cmbx9 \font\preloaded=cmbx8 \font\sevenbf=cmbx7 \font\preloaded=cmbx6 \font\fivebf=cmbx5 \font\tentt=cmtt10 \font\preloaded=cmtt9 \font\preloaded=cmtt8 \font\preloaded=cmsltt10 \font\tensl=cmsl10 \font\preloaded=cmsl9 \font\preloaded=cmsl8 \font\tenit=cmti10 \font\preloaded=cmti9 \font\preloaded=cmti8 \font\preloaded=cmti7 \font\preloaded=cmu10 \font\preloaded=cmmib10 \font\preloaded=cmbsy10 \font\preloaded=cmcsc10 \font\preloaded=cmssbx10 \font\preloaded=cmdunh10 \font\preloaded=cmr7 at 14.51799pt \font\preloaded=cmtt10 at 14.4pt \font\preloaded=cmssbx10 at 14.4pt \font\preloaded=manfnt 14787 words of font info for 50 preloaded fonts 14 hyphenation exceptions Hyphenation trie of length 6075 has 181 ops
Re: Cygwin: texi2dvi stumbles over texinfo.tex (was: failed checks for automake 1.9.6)
[ this is http://lists.gnu.org/archive/html/bug-automake/2006-05/msg1.html aka http://lists.gnu.org/archive/html/bug-texinfo/2006-05/msg00017.html and the original report is http://lists.gnu.org/archive/html/bug-automake/2006-04/msg00017.html ] Hello Cygwin folks, In the Automake testsuite, we're experiencing a bug with texi2dvi on Cygwin that looks like a problem with the Cygwin TeX distribution or setup. See Karl's comments and the cited references for details. It would be greatly appreciated if you could take a look -- thanks! * Karl Berry wrote on Sat, May 20, 2006 at 10:48:22PM CEST: | make[1]: Entering directory `/cygdrive/e/Programme/GNU/automake-1.9.6/tests/testSubDir/txinfo3-1.0/_build' | TEXINPUTS=..:$TEXINPUTS \ | MAKEINFO='/bin/sh /cygdrive/e/Programme/GNU/automake-1.9.6/tests/testSubDir/txinfo3-1.0/missing --run makeinfo -I +..' \ | texi2dvi ../textutils.texi | This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4) | file:line:error style messages enabled. | %-line parsing enabled. | ---! /var/lib/texmf/web2c/etex.fmt was written by pdfetex I believe it's a Cygwin problem and/or TeX installation problem on the particular machine. In essence, texi2dvi is doing this: echo '\input texinfo @bye' txiversion.tex tex txiversion.tex The error message from TeX means that the binary (tex, which was hardwired) being run is trying to load a .fmt that was written by something else (etex). It has nothing to do with the contents of the file. I'd expect tex story from the command line to fail in the same way. Usually the solution would be to rebuild the .fmt file with the right executable, and usually just removing the .fmt and then invoking the binary should do that (it is able to make the .fmt automatically these days, although I don't know if that happens with this Cygwin setup). In this case, it is not clear to me why running tex is trying to read etex.fmt (normally it would read tex.fmt); is Cygwin doing something with links or shell scripts? It is also not clear to me why PDF output works; I'd expect the same error, since the same tex binary gets invoked. I think you need to talk to whomever is responsible for the Cygwin TeX support. Cheers, Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin: texi2dvi stumbles over texinfo.tex (was: failed checks for automake 1.9.6)
On 23 May 2006 13:13, Ralf Wildenhues wrote: [ As per cygwin-L tradition, I am replying only to the lists; Ralf, if you see this and Karl does not, please feel free to forward it. ] In the Automake testsuite, we're experiencing a bug with texi2dvi on Cygwin that looks like a problem with the Cygwin TeX distribution or setup. See Karl's comments and the cited references for details. It would be greatly appreciated if you could take a look -- thanks! /cygdrive/e/Programme/GNU/automake-1.9.6/tests/testSubDir/txinfo3-1.0/missi ng --run makeinfo -I +..' \ texi2dvi ../textutils.texi This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4) file:line:error style messages enabled. %-line parsing enabled. ---! /var/lib/texmf/web2c/etex.fmt was written by pdfetex Oops. Pardon wrapping! I believe it's a Cygwin problem and/or TeX installation problem on the particular machine. In essence, texi2dvi is doing this: echo '\input texinfo @bye' txiversion.tex tex txiversion.tex The error message from TeX means that the binary (tex, which was hardwired) being run is trying to load a .fmt that was written by something else (etex). It has nothing to do with the contents of the file. Ok, you got me curious. How does TeX know what application wrote the file if it's not to do with the contents of that file? However, I've observed problems with cygwin's web2c/... files before, the perms can get messed up somehow and need chowning; they can end up owned by 'None', which means that everyone gets the O (out of UGO) perms, which in a lot of cases are '---', ie. access for user and group only. See http://www.cygwin.com/ml/cygwin/2004-03/msg00454.html for more; I don't know if this is the cause of your problem but I guess it's worth checking the perms on the relevant machine. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
