Re: [Context] minimals for cygwin
On 07/29/2010 08:44 PM, Peter Münster wrote:
On Wed, Jul 28 2010, Taco Hoekwater wrote:
- metapost does no more build (no problem with 1.500, but 1.501 and 1.502 fail)
I need the error report if you want me too look at it (same for the luatex stack dumping)
Hello Taco,
Please find attached the output of the build-script.
Something is broken in the build script, probably because of a 'make mpost' vs. 'make mpost.exe' issue. This bit:
gcc -g -O2 mpost.c -o mpost
is the best hint at what is wrong: make is not using any of the dependencies for mpost.c, which typically happens when you feed make the wrong target. Now I have the 'interesting' problem that I know what is wrong, but not exactly how to fix it. From LuaTeX's build.sh comes the following: case `uname` in MINGW32* ) LUATEXEXE=luatex.exe ;; esac clearly mpost's build.sh needs something similar, but I don't know for sure what 'uname' returns under cygwin. I've attached a version of metapost build.sh that has my best guess. Can you see whether it works? Best wishes, Taco
On Fri, Jul 30 2010, Taco Hoekwater wrote:
clearly mpost's build.sh needs something similar, but I don't know for sure what 'uname' returns under cygwin. I've attached a version of metapost build.sh that has my best guess.
Can you see whether it works?
Hello Taco, Yes, your guess was right, the output of uname is "CYGWIN_NT-5.1" and it is working now. Thanks, Peter -- Contact information: http://pmrb.free.fr/contact/
On 07/30/2010 12:13 PM, Peter Münster wrote:
On Fri, Jul 30 2010, Taco Hoekwater wrote:
clearly mpost's build.sh needs something similar, but I don't know for sure what 'uname' returns under cygwin. I've attached a version of metapost build.sh that has my best guess.
Can you see whether it works?
Hello Taco,
Yes, your guess was right, the output of uname is "CYGWIN_NT-5.1" and it is working now.
Great. Can you add that CYGWIN case line to luatex's build.sh to see whether that fixes that crash as well? Best wishes, Taco
On Fri, Jul 30 2010, Taco Hoekwater wrote:
Great. Can you add that CYGWIN case line to luatex's build.sh to see whether that fixes that crash as well?
No, there is still a crash after the creation of the pdf. Peter -- Contact information: http://pmrb.free.fr/contact/
On 07/30/2010 03:53 PM, Peter Münster wrote:
On Fri, Jul 30 2010, Taco Hoekwater wrote:
Great. Can you add that CYGWIN case line to luatex's build.sh to see whether that fixes that crash as well?
No, there is still a crash after the creation of the pdf.
Can you send me that stackdump (assuming it was actually created)?
On Fri, Jul 30 2010, Taco Hoekwater wrote:
Can you send me that stackdump (assuming it was actually created)?
Here is it: Stack trace: Frame Function Args 0022C948 7C802542 (00000648, 0000EA60, 000000A4, 0022CA3C) 0022CA58 610C26D3 (00000000, 7C802600, 7C802542, 00000000) 0022CB38 610BF387 (00000000, 00000000, 00000000, 00000000) 0022CB88 610BF79B (00000990, 0022CBB0, 0022CB98, 67F0A00C) 0022CC48 610BF8C1 (00000990, 00000006, 0022CC78, 610BF965) 0022CC58 610BF8FC (00000006, 0022CE80, 00000000, 00000000) 0022CC78 610BF965 (67F0A00C, 00000000, 6115B10C, 006B8448) 0022CC98 67F05531 (0080D000, 67F05550, 0022CCB8, 61004C69) 0022CCA8 00401119 (00000000, 00000002, 0022CCE8, 6113AEE7) 0022CCB8 61004C69 (6115DD10, 00000000, 00000000, 00000000) 0022CCE8 6113AEE7 (00000000, 00000000, 0022CD18, 0042FB46) 0022CD08 61112E0A (00000000, 61225A1C, 0022CD28, 610BC8B6) 0022CD18 61004EA1 (00000000, 00000000, 0022CD38, 0042E6E1) 0022CD28 610BC8B6 (00000000, 61225A1C, 0022CD58, 00401934) 0022CD38 0042E6E1 (00000004, 61225A1C, 0022CD68, 0022CD70) 0022CD58 00401934 (6122A037, 6116CFFF, 0022CD98, 61006E73) End of stack trace (more stack frames may be present) And here the output of the command (calling luatex directly, without context): $ luatex --fmt=/opt/context/tex/texmf-cache/luatex-cache/context/7d370800340afacef61537f2a7d8e93a/formats/cont-en --lua=/opt/context/tex/texmf-cache/luatex-cache/context/7d370800340afacef61537f2a7d8e93a/formats/cont-en.lui test This is LuaTeX, Version beta-0.61.0-2010073015 \write18 enabled. sorters > setting language 'en' (test.tex publications : loading formatting style from bxml-apa (/opt/context/tex/texmf-context/tex/context/base/bxml-apa.mkiv) ConTeXt ver: 2010.07.27 16:30 MKIV fmt: 2010.7.28 int: english/english system : cont-new loaded (/opt/context/tex/texmf-context/tex/context/base/cont-new.tex systems : beware: some patches loaded from cont-new.tex (/opt/context/tex/texmf-context/tex/context/base/cont-new.mkiv)) system : cont-fil loaded (/opt/context/tex/texmf-context/tex/context/base/cont-fil.tex loading : ConTeXt File Synonyms ) system : cont-sys loaded (/opt/context/tex/texmf-local/tex/context/peter/cont-sys.tex (/opt/context/tex/texmf-context/tex/context/user/cont-sys.rme (/opt/context/tex/texmf-context/tex/context/base/type-def.mkiv) (/opt/context/tex/texmf-context/tex/context/base/type-lua.mkiv) (/opt/context/tex/texmf-context/tex/context/base/type-siz.mkiv) (/opt/context/tex/texmf-context/tex/context/base/type-otf.mkiv)) (/opt/context/tex/texmf-local/tex/context/peter/dd-macros.tex loading : Macros for Delta Dore )) system : test.top loaded (test.top) fonts : preloading latin modern fonts {/opt/context/tex/texmf/fonts/map/dvips/lm/lm-math.map}{/opt/context/tex/texmf/fonts/map/dvips/lm/lm-rm.map}{/opt/context/tex/texmf-context/fonts/map/pdftex/context/mkiv-base.map} bodyfont : 12pt rm is loaded language : language en is active gcc -shared -o testmod.so testmod.c /usr/lib/liblua.dll.a systems : begin file test at line 28 pages > flushing realpage 1, userpage 1, subpage 1 systems : end file test at line 30 ) mkiv lua stats : used config file - /opt/context/tex/texmf/web2c/texmfcnf.lua mkiv lua stats : used cache path - /opt/context/tex/texmf-cache/luatex-cache/context/2722fb5579b835691c1495c9a8e6b040 mkiv lua stats : input load time - 0.047 seconds mkiv lua stats : stored bytecode data - 228 modules, 54 tables, 282 chunks mkiv lua stats : node list callback tasks - 6 unique task lists, 5 instances (re)created, 332 calls mkiv lua stats : cleaned up reserved nodes - 36 nodes, 9 lists of 410 mkiv lua stats : node memory usage - 20 glue_spec mkiv lua stats : used backend - pdf (backend for directly generating pdf output) mkiv lua stats : loaded patterns - en::2 mkiv lua stats : language load time - 0.063 seconds , nofpatterns: 1 mkiv lua stats : callbacks - direct: 483, indirect: 4564, total: 5047 mkiv lua stats : lxml preparation time - 0.000 seconds, 0 nodes, 11 lpath calls, 0 cached calls mkiv lua stats : result saved in file - test.pdf mkiv lua stats : loaded fonts - 33 files: stmary10.afm lmmono12-regular.otf lmmono8-regular.otf lmmono9-regular.otf lmroman12-bold.otf lmroman12-regular.otf lmroman7-bold.otf lmroman7-regular.otf lmroman9-bold.otf lmroman9-regular.otf lmsans12-regular.otf lmsans8-regular.otf lmsans9-regular.otf eufb10.tfm eufb7.tfm eufm10.tfm eufm7.tfm msam10.tfm msam7.tfm msbm10.tfm msbm7.tfm lmex10.tfm lmmi12.tfm lmmi7.tfm lmmi9.tfm lmmib10.tfm lmmib7.tfm lmsy10.tfm lmsy7.tfm lmsy9.tfm rm-lmr12.tfm rm-lmr7.tfm rm-lmr9.tfm mkiv lua stats : fonts load time - 0.750 seconds mkiv lua stats : luatex banner - this is luatex, version beta-0.61.0-2010073015 mkiv lua stats : control sequences - 30968 of 165536 mkiv lua stats : current memory usage - 33 MB (ctx: 34 MB) mkiv lua stats : runtime - 3.234 seconds, 1 processed pages, 1 shipped pages, 0.309 pages/second Aborted (core dumped) Peter -- Contact information: http://pmrb.free.fr/contact/
On 07/30/2010 04:13 PM, Peter Münster wrote:
On Fri, Jul 30 2010, Taco Hoekwater wrote:
Can you send me that stackdump (assuming it was actually created)?
Here is it:
Stack trace: Frame Function Args 0022C948 7C802542 (00000648, 0000EA60, 000000A4, 0022CA3C) 0022CA58 610C26D3 (00000000, 7C802600, 7C802542, 00000000) 0022CB38 610BF387 (00000000, 00000000, 00000000, 00000000) 0022CB88 610BF79B (00000990, 0022CBB0, 0022CB98, 67F0A00C) 0022CC48 610BF8C1 (00000990, 00000006, 0022CC78, 610BF965) 0022CC58 610BF8FC (00000006, 0022CE80, 00000000, 00000000) 0022CC78 610BF965 (67F0A00C, 00000000, 6115B10C, 006B8448) 0022CC98 67F05531 (0080D000, 67F05550, 0022CCB8, 61004C69) 0022CCA8 00401119 (00000000, 00000002, 0022CCE8, 6113AEE7) 0022CCB8 61004C69 (6115DD10, 00000000, 00000000, 00000000) 0022CCE8 6113AEE7 (00000000, 00000000, 0022CD18, 0042FB46) 0022CD08 61112E0A (00000000, 61225A1C, 0022CD28, 610BC8B6) 0022CD18 61004EA1 (00000000, 00000000, 0022CD38, 0042E6E1) 0022CD28 610BC8B6 (00000000, 61225A1C, 0022CD58, 00401934) 0022CD38 0042E6E1 (00000004, 61225A1C, 0022CD68, 0022CD70) 0022CD58 00401934 (6122A037, 6116CFFF, 0022CD98, 61006E73) End of stack trace (more stack frames may be present)
That doesn't help one bit :( Can you please do a luatex build like this $ export CFLAGS='-g -O0' $ ./build.sh --nostrip and send me the stack dump from that? (or better yet, a gdb backtrace?). Best wishes, Taco
On Fri, Jul 30 2010, Taco Hoekwater wrote:
Can you please do a luatex build like this
$ export CFLAGS='-g -O0' $ ./build.sh --nostrip
and send me the stack dump from that? (or better yet, a gdb backtrace?).
Hello Taco, Here comes the backtrace: mkiv lua stats : luatex banner - this is luatex, version beta-0.61.0-2010082413 mkiv lua stats : control sequences - 30968 of 165536 mkiv lua stats : current memory usage - 33 MB (ctx: 34 MB) mkiv lua stats : runtime - 3.547 seconds, 1 processed pages, 1 shipped pages, 0.282 pages/second Program received signal SIGABRT, Aborted. 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll (gdb) backtrace #0 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll #1 0x7c91d91c in ntdll!ZwQuerySystemInformation () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x610995f6 in winpids::enum_processes () from /usr/bin/cygwin1.dll #3 0x61099941 in winpids::set () from /usr/bin/cygwin1.dll #4 0x610c2ab0 in kill_pgrp () from /usr/bin/cygwin1.dll #5 0x61004f11 in do_exit () from /usr/bin/cygwin1.dll #6 0x610c2fb1 in abort () from /usr/bin/cygwin1.dll #7 0x67f05531 in cyggcc_s-1!__deregister_frame_info_bases () from /usr/bin/cyggcc_s-1.dll #8 0x00401119 in __gcc_deregister_frame () #9 0x61004a29 in do_global_dtors () from /usr/bin/cygwin1.dll #10 0x6113ea97 in __call_exitprocs () from /usr/bin/cygwin1.dll #11 0x61116b7a in exit () from /usr/bin/cygwin1.dll #12 0x61004c6b in cygwin_exit () from /usr/bin/cygwin1.dll #13 0x610bfea5 in _sigfe () from /usr/bin/cygwin1.dll #14 0x0022cbc8 in ?? () #15 0x61122a04 in fflush () from /usr/bin/cygwin1.dll #16 0x004391d0 in do_final_end () at ../../../source/texk/web2c/luatexdir/tex/errors.w:164 #17 0x0043b700 in main_body () at ../../../source/texk/web2c/luatexdir/tex/mainbody.w:482 #18 0x00401785 in main (ac=4, av=0x16373c0) at ../../../source/texk/web2c/luatexdir/luatex.c:461 (gdb) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
Peter Münster wrote:
On Fri, Jul 30 2010, Taco Hoekwater wrote:
Can you please do a luatex build like this
$ export CFLAGS='-g -O0' $ ./build.sh --nostrip
and send me the stack dump from that? (or better yet, a gdb backtrace?).
Weird indeed. Can you try a build with this patch? Index: source/texk/web2c/luatexdir/tex/errors.w =================================================================== --- source/texk/web2c/luatexdir/tex/errors.w (revision 3829) +++ source/texk/web2c/luatexdir/tex/errors.w (working copy) @@ -156,7 +156,7 @@ __attribute__ ((noreturn)) void do_final_end(void) { - update_terminal(); + /* |update_terminal();| */ ready_already = 0; if ((history != spotless) && (history != warning_issued)) uexit(1);
On Tue, Aug 24 2010, Taco Hoekwater wrote:
Weird indeed. Can you try a build with this patch?
Index: source/texk/web2c/luatexdir/tex/errors.w =================================================================== --- source/texk/web2c/luatexdir/tex/errors.w (revision 3829) +++ source/texk/web2c/luatexdir/tex/errors.w (working copy) @@ -156,7 +156,7 @@ __attribute__ ((noreturn)) void do_final_end(void) { - update_terminal(); + /* |update_terminal();| */ ready_already = 0; if ((history != spotless) && (history != warning_issued)) uexit(1);
The backtrace is now different: Program received signal SIGABRT, Aborted. 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll (gdb) backtrace #0 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll #1 0x7c91d91c in ntdll!ZwQuerySystemInformation () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x610995f6 in winpids::enum_processes () from /usr/bin/cygwin1.dll #3 0x61099941 in winpids::set () from /usr/bin/cygwin1.dll #4 0x610c2ab0 in kill_pgrp () from /usr/bin/cygwin1.dll #5 0x61004f11 in do_exit () from /usr/bin/cygwin1.dll #6 0x610c2fb1 in abort () from /usr/bin/cygwin1.dll #7 0x67f05531 in cyggcc_s-1!__deregister_frame_info_bases () from /usr/bin/cyggcc_s-1.dll #8 0x00401119 in __gcc_deregister_frame () #9 0x61004a29 in do_global_dtors () from /usr/bin/cygwin1.dll #10 0x6113ea97 in __call_exitprocs () from /usr/bin/cygwin1.dll #11 0x61116b7a in exit () from /usr/bin/cygwin1.dll #12 0x61004c6b in cygwin_exit () from /usr/bin/cygwin1.dll #13 0x610bfea5 in _sigfe () from /usr/bin/cygwin1.dll #14 0x00000002 in ?? () #15 0x00000010 in ?? () #16 0x01e88300 in ?? () #17 0x8c25d0a3 in ?? () #18 0x25d0a100 in ?? () #19 0xc085008c in ?? () #20 0xb70fd57f in ?? () #21 0x75f1a005 in ?? () #22 0xf8836600 in ?? () #23 0x00860f01 in unicode4_size () #24 0xc7000001 in ?? () #25 0x54682404 in ?? () #26 0x5ae8007c in ?? () #27 0x0f000060 in ?? () #28 0xf1a005b7 in ?? () #29 0xb70f0075 in ?? () #30 0x01e883c0 in ?? () #31 0xfac1c289 in ?? () #32 0x2404891f in ?? () #33 0x04245489 in ?? () #34 0x006596e8 in Annot::generateFieldAppearance (this=Cannot access memory at address 0x8c25d0a9 ) at ../../../source/libs/xpdf/xpdf-3.02/xpdf/Annot.cc:649 Cannot access memory at address 0x8c25d0a5 (gdb) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
Hi Peter, Peter Münster wrote:
) at ../../../source/libs/xpdf/xpdf-3.02/xpdf/Annot.cc:649 Cannot access memory at address 0x8c25d0a5
This is very different indeed. I don't see why a crash that happened after application close and was fixed there now suddenly happens way before the application close, unless it is related to C++ memory freeing. And even then, I have no idea what goes wrong and why. Anyway, can you try the released 0.62.0 ? Best wishes, Taco
On Tue, Aug 24 2010, Taco Hoekwater wrote:
This is very different indeed. I don't see why a crash that happened after application close and was fixed there now suddenly happens way before the application close, unless it is related to C++ memory freeing. And even then, I have no idea what goes wrong and why. Anyway, can you try the released 0.62.0 ?
Yes. The results are the same: Unpatched luatex: mkiv lua stats : runtime - 3.469 seconds, 1 processed pages, 1 shipped pages, 0.288 pages/second Program received signal SIGABRT, Aborted. 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll (gdb) backtrace #0 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll #1 0x7c91d91c in ntdll!ZwQuerySystemInformation () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x610995f6 in winpids::enum_processes () from /usr/bin/cygwin1.dll #3 0x61099941 in winpids::set () from /usr/bin/cygwin1.dll #4 0x610c2ab0 in kill_pgrp () from /usr/bin/cygwin1.dll #5 0x61004f11 in do_exit () from /usr/bin/cygwin1.dll #6 0x610c2fb1 in abort () from /usr/bin/cygwin1.dll #7 0x67f05531 in cyggcc_s-1!__deregister_frame_info_bases () from /usr/bin/cyggcc_s-1.dll #8 0x00401119 in __gcc_deregister_frame () #9 0x61004a29 in do_global_dtors () from /usr/bin/cygwin1.dll #10 0x6113ea97 in __call_exitprocs () from /usr/bin/cygwin1.dll #11 0x61116b7a in exit () from /usr/bin/cygwin1.dll #12 0x61004c6b in cygwin_exit () from /usr/bin/cygwin1.dll #13 0x610bfea5 in _sigfe () from /usr/bin/cygwin1.dll #14 0x0022cba8 in ?? () #15 0x61122a04 in fflush () from /usr/bin/cygwin1.dll #16 0x004391dc in do_final_end () at ../../../source/texk/web2c/luatexdir/tex/errors.w:164 #17 0x0043b754 in main_body () at ../../../source/texk/web2c/luatexdir/tex/mainbody.w:482 #18 0x00401785 in main (ac=5, av=0x17073f0) at ../../../source/texk/web2c/luatexdir/luatex.c:461 (gdb) kill Kill the program being debugged? (y or n) y (gdb) quit Patched luatex: mkiv lua stats : luatex banner - this is luatex, version beta-0.62.0-2010082510 mkiv lua stats : control sequences - 30988 of 165536 mkiv lua stats : current memory usage - 32 MB (ctx: 33 MB) mkiv lua stats : runtime - 3.469 seconds, 1 processed pages, 1 shipped pages, 0.288 pages/second Program received signal SIGABRT, Aborted. 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll (gdb) backtrace #0 0x6105c930 in fhandler_tty_slave::close () from /usr/bin/cygwin1.dll #1 0x7c91d91c in ntdll!ZwQuerySystemInformation () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x610995f6 in winpids::enum_processes () from /usr/bin/cygwin1.dll #3 0x61099941 in winpids::set () from /usr/bin/cygwin1.dll #4 0x610c2ab0 in kill_pgrp () from /usr/bin/cygwin1.dll #5 0x61004f11 in do_exit () from /usr/bin/cygwin1.dll #6 0x610c2fb1 in abort () from /usr/bin/cygwin1.dll #7 0x67f05531 in cyggcc_s-1!__deregister_frame_info_bases () from /usr/bin/cyggcc_s-1.dll #8 0x00401119 in __gcc_deregister_frame () #9 0x61004a29 in do_global_dtors () from /usr/bin/cygwin1.dll #10 0x6113ea97 in __call_exitprocs () from /usr/bin/cygwin1.dll #11 0x61116b7a in exit () from /usr/bin/cygwin1.dll #12 0x61004c6b in cygwin_exit () from /usr/bin/cygwin1.dll #13 0x610bfea5 in _sigfe () from /usr/bin/cygwin1.dll #14 0x00000002 in ?? () #15 0x00000010 in ?? () #16 0x01e88300 in ?? () #17 0x8f55d0a3 in ?? () #18 0x55d0a100 in ?? () #19 0xc085008f in ?? () #20 0xb70fd57f in ?? () #21 0x78a1a005 in ?? () #22 0xf8836600 in ?? () #23 0x00860f01 in ____utype () #24 0xc7000001 in ?? () #25 0xe5082404 in ?? () #26 0x5ae8007e in ?? () #27 0x0f000060 in ?? () #28 0xa1a005b7 in ?? () #29 0xb70f0078 in ?? () #30 0x01e883c0 in ?? () #31 0xfac1c289 in ?? () #32 0x2404891f in ?? () #33 0x04245489 in ?? () #34 0x006596e8 in AnnotWidget::layoutText (this=Cannot access memory at address 0x8f55d0a9 ) at ../../../source/libs/poppler/poppler-0.12.4/poppler/Annot.cc:2246 Cannot access memory at address 0x8f55d0a5 (gdb) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On Wed, Aug 25 2010, Peter Münster wrote:
On Tue, Aug 24 2010, Taco Hoekwater wrote:
This is very different indeed. I don't see why a crash that happened after application close and was fixed there now suddenly happens way before the application close, unless it is related to C++ memory freeing. And even then, I have no idea what goes wrong and why. Anyway, can you try the released 0.62.0 ?
Yes. The results are the same:
Let's drop support for cygwin. Ok? Peter -- Contact information: http://pmrb.free.fr/contact/
Peter Münster wrote:
On Wed, Aug 25 2010, Peter Münster wrote:
On Tue, Aug 24 2010, Taco Hoekwater wrote:
This is very different indeed. I don't see why a crash that happened after application close and was fixed there now suddenly happens way before the application close, unless it is related to C++ memory freeing. And even then, I have no idea what goes wrong and why. Anyway, can you try the released 0.62.0 ? Yes. The results are the same:
Let's drop support for cygwin. Ok?
Two things that might help debug the problem: * what is the gcc version is that version of cygwin? * Is there any chance of trying with a different compiler version? Also, are you running the resulting luatex in a command box, or in a real shell? What I think _may_ be the problem is that the c++ garbage collector is run too late or too early, resulting in reads or writes to file descriptors that are already closed. But I have no idea why and how that could happen unless it is either a compiler bug or you are running into a conflict between (y)our usage patterns and the cygwin runtime dll. You could even try to compile with -no-cygwin to get rid of the runtime dll dependency (I don't remember the exact flags needed for that, sorry). But then, if you wanted to do that, you probably would have used the mingw compiler from the start ... Anyway, this sort of trouble is exactly why I abandonded cygwin in the mid-nineties: it seems that whatever you do at the system level (either in windows style or in unix style), cygwin is always doing something unexpected behind your back. Maybe I am wrong and I simply do not understand the system enough, but that was definitely the impression I got. Best wishes, Taco
On Thu, Aug 26 2010, taco wrote:
Let's drop support for cygwin. Ok?
Two things that might help debug the problem:
All right Taco, so you really want, that we continue to spend time on this matter ... !
* what is the gcc version is that version of cygwin?
4.3.4
* Is there any chance of trying with a different compiler version?
Yes. Today I've tested 3.4.4: no problem!
Also, are you running the resulting luatex in a command box, or in a real shell?
ssh-connection (a bash shell)
You could even try to compile with -no-cygwin to get rid of the runtime dll dependency (I don't remember the exact flags needed for that, sorry). But then, if you wanted to do that, you probably would have used the mingw compiler from the start ...
Indeed, the only reason for compiling with cygwin, is just this runtime dll. There is still the normal windows version, that works. It just can't load shared cygwin dlls.
Anyway, this sort of trouble is exactly why I abandonded cygwin in the mid-nineties
Good decision! Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On 08/27/2010 01:25 PM, Peter Münster wrote:
On Thu, Aug 26 2010, taco wrote:
Let's drop support for cygwin. Ok?
Two things that might help debug the problem:
All right Taco, so you really want, that we continue to spend time on this matter ... !
Well, I am not exactly jumping with joy.
* Is there any chance of trying with a different compiler version?
Yes. Today I've tested 3.4.4: no problem!
I was afraid of that. I hope you don't mind, but at this point I do not really care any more, as it seems to be a compiler bug.
Also, are you running the resulting luatex in a command box, or in a real shell?
ssh-connection (a bash shell)
There is a good chance that it will work ok in an actual shell... Best wishes, Taco
participants (3)
-
Peter Münster -
taco -
Taco Hoekwater