RE: gcc-dw2? or fast sjlj-exceptions EH
On 11-Sep-2007, Danny Smith wrote: | At http://www.cygwin.com/ml/cygwin/2007-09/msg00194.html | | Tatsuro Matsuoka wrote: | | The best solution, I think, the speed of sjlj-exceptions EH on the | cygwin is as fast as that of other platforms. | | | In the case of octave, I believe that the main cause of slowdown is the | sjlj EH code generated in prologue of new() | Does a no-throw override of libary version of these functions help ? Octave does not set up a new handler because it expects that a failed allocation will throw a std::bad_alloc exception. Given that, it seems that the replacement for operator new that you posted would cause Octave to crash on a failed allocation, and that's not an acceptable solution for an interactive system like Octave. If we did install a new handler, could it throw a std::bad_alloc exception and still avoid the performance problem? I don't see how, as it seems that would just be pushing the problem one function call level deeper but without any real change in the way things work. It's also not acceptable to install a new handler that doesn't throw an exception but just does a longjmp because then all the nice cleanup things that are supposed to happen with exception handling are bypassed when recovering from the failed allocation. jwe -- 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: octave compiled with gcc-3.4.4-2 - error messages during make check
On 21-Aug-2006, Dave Korn wrote: | Then, keeping the | dll constant, try rolling your gcc install back to 3.4.4-1, building in a | fresh object dir, and running make check there. Please let us know what | results you get. This won't work for Octave because it is a victim of the std::string bug in the 3.4.4-1 package. Without some fix for that problem, Octave segfaults on startup. jwe -- 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: change in behavior of make from 3.80 to 3.81
On 16-Aug-2006, William A. Hoffman wrote: | Without your support, I don't think the patch would get far. | I am thinking the patch would be something like: | | #ifdef CYGWIN | #define HAVE_DOS_PATHS | #endif Have you tried this (uh, what file are you patching anyway)? Does it work? Does it cause problems for valid Makefiles that assume POSIX filenames? Suggesting changes to GNU Make on this list is not going to cause things to happen. If you want to see changes, then I think the place to start is to * get a copy of the current GNU Make sources * apply your above patch * build and test it * if it works, submit the patch to the GNU Make maintainers in the appropriate forum (not here) explaining why the patch is needed and whether there are any potential hazards to watch out for if the change is made jwe -- 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: change in behavior of make from 3.80 to 3.81
On 15-Aug-2006, Joachim Achtzehnter wrote: | Free software is about collaboration of a community consisting of | developers, users, documentation authors, testers, translators, etc. to a | common good, namely the production of good software that serves the needs | of that community. In my view, people who are doing the work, whether that is writing code, doing testing, writing documentation, or some other useful job, are developers. Some users are developers. The ones that just want something for nothing are not much help to me. | A peculiar aspect of all-volunteer free software | projects (some are wholly or partially funded where this can be different) | is that nobody can force another member of the community to do something | they don't want to do, so it is all based on persuasion and winning over | others by argument. In my experience, people who just want to persuade others to do work for them without actually contributing any work back to a project are not very helpful. Ideas are easy to come by. The work to implement them is not. | You make it appear as if a handful of developers are | making a contribution and everybody else is just getting a gratis | benefit without contributing. Again, my experience has been that this is generally the way things work in free software projects. A few people do almost all of the work and a lot of others benefit without contributing. | Clearly, developers make a huge contribution, | nobody is denying this, but to suggest that *only* developers contribute | and everybody else should therefore just shut up I never said everyone else should just shut up. My point was that if you aren't contributing in some way, then you shouldn't expect your complaining to carry much weight. The way to get things done is to do the work, not just complain and hope that people do something for you. | A healthy free software project | depends on and welcomes input from the community. Sometimes, the input becomes annoying. When this happens, do you expect the people doing the work to just sit back and take it? | The attitude exhibited by | some on this mailing list, of trying to muzzle opinions they disagree with, | does not help. How are people on the mailing list being muzzled? If that were the case, then I would think there would have been a lot fewer messages about this topic on the list. Obligatory-make-behavior-content: It seems there is really no need for this discussion now, as there are several options available for someone willing to do the work: * Use the MinGW version of make to build your projects. * Patch your own version of GNU Make for Cygwin (I don't think that the patch used with the previous version is a secret). * Get the necessary changes adopted in the mainline GNU Make sources. jwe -- 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: change in behavior of make from 3.80 to 3.81
A recap, as I understand it (please correct me if I'm wrong): * The version of GNU Make for Cygwin used to support MS-DOS filenames. This feature was not part of GNU Make if you compiled the sources for Cygwin out of the box, but was something that was added and maintained as a separate patch. * The maintainer of the GNU Make package grew weary of maintaining the patch and decided to drop it. * Lots of people are complaining. * The maintainer of the GNU Make package for Cygwin has repeatedly made it clear that no amount of complaining will result in the patch being maintained and applied to any future GNU Make package for Cygwin. My understanding is that the central problem is the amount of effort required to update the patch with each new release of GNU Make, not that the feature itself is necessarily bad, though there may be some obscure problems such that it would be better if the feature could be optional, either with a command-line option or special Makefile directive. * You are now taking this to mean that the Cygwin maintainers don't care about users and you are suggesting that this could result in a fork of Cygwin (good luck with that). Please, this makes absolutely no sense. This whole problem could be solved if the people who are complaining about the Cygwin version of GNU Make directed their efforts toward getting a patch accepted in the GNU Make sources that handles MS-DOS style filenames when GNU Make is compiled for Cygwin. Then there would be no need to maintain a separate patch just for the Cygwin package of GNU Make. Or am I missing something? jwe -- 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: change in behavior of make from 3.80 to 3.81
On 15-Aug-2006, Dave Korn wrote: | On 14 August 2006 23:51, John W. Eaton wrote: | | Or am I missing something? | | The increasingly obvious fact that the aforementioned people have no | intention of actually *doing* anything, and seem to want to do nothing except | complain and tell others what they ought to be doing, rather than actually | getting something done? Oh yeah, I started writing that paragraph but then deleted it since it seemed to be so much stating the obvious that I even recognized it as beating the mummified horse. I mean, isn't free software all about getting something for nothing, then complaining about it and expecting others to do yet more gratis work for you? jwe -- 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: 3.81 and windows paths
On 28-Jul-2006, Paul D. Smith wrote: | Regardless, I still wonder whether my idea of building make for a POSIX | environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would | work. If this could cause some valid Makefiles to do the wrong thing as cgf suggests might happen, then can we at least make the behavior optional, perhaps with a command line option or magic target (maybe .WINDOWS_FILENAMES:)? That way, people who don't ask for the special feature won't be bitten by it. Thanks, jwe -- 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: 3.81 and windows paths
On 28-Jul-2006, Chris Taylor wrote: | So even if the DOS #ifdef was enabled, we'd be back at the point of | having patches to attempt to fix this behaviour. | Unless there was some way of having two versions of make - one with this | behaviour and one without, controlled by /etc/alternatives perhaps? Two versions for this seemingly small feature seems a bit much when a command-line switch could do the job. jwe -- 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: 3.81 and windows paths
On 28-Jul-2006, Paul D. Smith wrote: | This would be very tricky: right now all the code to do DOS vs. POSIX | pathnames is controlled through #ifdefs, so it's a compile-time thing. | Changing it to a runtime thing would be a lot of work, I think... the OK, but I still think it should be implemented as an optional feature that users can select unless we can prove that the feature doesn't cause trouble for valid Makefiles that use only Posix filenames. | #ifdeffing in GNU make is kind of a mess, with all the different ports | we support. Yes, that's unfortunate. I don't think that it is necessary to use an intricate mess of #ifdefs all throughout a program to achieve portability to a wide variety of systems. That seems to be a design decision that was made fairly early on in the development of Make (long before you became the maintainer, I would guess). jwe -- 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: Fixing the state of C++ in Cygwin
On 27-Apr-2006, Angelo Graziosi wrote: | In the Cygwin distribution there are packages like Octave that are | incompatible with gcc-3.4.4-1, yet. Octave on Cygwin would also be helped if libstdc++ were built as a DLL. Has there been any progress on that? Is there anyone else who is interested in having a DLL for libstdc++? If there are problems that prevent this from happning, what are they? Thanks, jwe -- 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/
using 'mkoctfile'
On 28-Feb-2006, Agnes Bousquier wrote: |I am using Octave 2.1.72 under cygwin and would like to generate .oct | files thanks to the command 'mkoctfile'. Unfortunately, when I type | mkoctfile myfile.cc | the following message appears (in French) : | /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld : | can not find -lreadline | collect2 : ld returned an execution state code | Could anyone please tell me what is missing ? I'm not sure why the readline library is not found. It should be installed with just about any Cygwin install, and I think it is a dependency of the Octave package. But in any case, I think you need to be using gcc 3.3, otherwise you will likely have problems. There is more information here: http://cygwin.com/ml/cygwin/2006-02/msg00738.html. jwe -- 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/
Octave's oct-modules built with gcc-3.4.4-1 crash octave.
On 21-Feb-2006, Juhani Saastamoinen wrote: | The binary octave modules compiled with gcc-3.4.4 don't work. The last time I checked, Octave just doesn't work with gcc 3.4 on Cygwin systems. I think the biggest problem is this bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 which was also discussed in this thread: http://cygwin.com/ml/cygwin/2006-01/msg00297.html and there also seems to be a related problem here: http://cygwin.com/ml/cygwin/2006-01/msg00495.html though I'm not sure that these two problems are precisely the same bug. | Installing the gcc-3.3.3-3 compiler version makes oct modules | work again. I use a 'myones.cpp' code as an example below. If you are using the binary package from a Cygwin mirror, then I think you will have to use gcc 3.3 to built .oct files. I'm fairly certain that the binary package of Octave is built with gcc 3.3, and it is best to not mix C++ compiler versions when building .oct files. jwe -- 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: [octave ] LOADPATH recurses only one level of subdirectories (on network drives)
On 14-Feb-2006, Eric Blake wrote: | so it is a | bug in octave if it is mis-optimizing traversal in the presence of a | directory link count of 1. It might make sense, though, for cygwin to set | the link count to 0 on remote directories (rather than 1), to make it | obvious that the link count really is unknown, but this still does not | take the blame off of octave for the mis-optimization. If we are playing the blame game, then let's assign some of the blame to the kpathsearch library, which is the basis for Octave's path searching code. jwe -- 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: once more unto the breech - still hanging, but I have a little more info.
|You just dumped 5 meg of useless spam into the inboxes of several | thousand people. You just ate up dozens of gigabytes of | sourceware.org's bandwidth, which are a scarce resource, paid for | out of hard-earned donations and sponsorship. Sorry to waste additional bandwith with this potentially obvious question, but if this is a big problem, then why not place limits on the size of posts going to the list? jwe -- 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/
[octave ] LOADPATH recurses only one level of subdirectories
On 9-Feb-2006, Larrie Carr wrote:
| In short, octave-forge is non-functional as it uses multiple subdirectories.
If that's true for everyone, then I'm surprised as I think you are the
first to report it.
| I've been looking through the sources and nothing has sprung up. Did find a
| cut-and-paste code error in oct_file_in_path() in utils.cc where the string
| length is not properly checked. Look like a cut and paste from
| fcn_file_in_path(). But this is for a different group.
Probably the code you are looking for is the function do_subdir in
liboctave/kpse.cc. This file contains a stripped-down version of the
kpathsearch library. Most modifications were to remove TeX-specific
stuff and to convert it to use std::string instead of plain C strings
which historically leaked memory. In any case, that function may use
an optimization to decide when to check for subdirectories. The
optimization looks at the link count of the current directory. If it
is 2, then the assumption is that the current directory does not
contain any subdirectories. That seems to work fine for Unixy
systems. Does that assumption not hold for Cygwin? If so, then I
think the fix is fairly simple as there is also Windows-specific code
in that function. Whether the optimization is performed depends on
what is #defined at compile time, so you'll probably have to do some
checking on a Cygwin system to see what is really going on.
| int len = name.length();
|
| if( len 0) {
|if (len 2 name [ len-4] == '.' name [len-3] == 'o'
|name[len-2] == 'c' name [len-1] =='t')
I've fixed this in my sources.
If you find other bugs in Octave, please report them to
[EMAIL PROTECTED]
Thanks,
jwe
--
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: gnuplot dependency in octave
On 8-Dec-2005, Igor Pechtchanski wrote: | What about http://cygwin.com/ml/cygwin/2005-12/msg00339.html (which | fails gracefully if gnuplot isn't installed)? Or does octave-forge | already do the right thing (tm) with respect to a missing gnuplot (i.e., | print out a meaningful error message, such as plotting disabled since | gnuplot is not installed -- please install it to plot)? Here is what Octave does if it tries to run a nonexistent gnuplot: octave:1 gnuplot_binary = foobar gnuplot_binary = foobar octave:2 sombrero (41) octave:3 sh: foobar: command not found warning: connection to external plotter (pid = 25466) lost -- warning: please try your plot command(s) again warning: broken pipe -- some output may be lost So the user gets some idea that there is a problem, but I would bet that this will confuse a lot of people. My preference would be for it to work out of the box, but that is not really the case yet, even if you have the gnuplot package installed. The problem is that the Cygwin version of gnuplot requires X to put a pretty plot on the screen but Octave does not require X to start. So if you run Octave in a Cygwin terminal (no X) then try a plot command, Octave will think that the plot command succeeded, but nothing will appear on the screen. Maybe gnuplot should be giving an error when the terminal is set to X11 but the X server is not available, but it does not. The gnuplot sources already have a way to open a native Windows window for plotting, but that code is not used for the Cygwin version of gnuplot (which uses X instead of the native Windows terminal driver). It would be really sweet if the Cygwin gnuplot could be made to use the native Windows terminal driver. jwe -- 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: octave-forge dependency?
OK, let's back up a bit, and see why kpsexpand is needed in the first
place.
Graphics in Octave use gnuplot. The legend function from Octave Forge
sends a save FILE command to gnuplot so that it can extract some
information about gnuplot's current state. If you do the following
mv /usr/bin/kpsexpand. /usr/bin/kpsexpand-save
gnuplot
...
gnuplot save foo
you should see the errors
sh: kpsexpand: command not found
So, why does gnuplot need kpsexpand to save state? Looking at the
gnuplot sources, one finds
/* Yet, no special font paths for these operating systems:
* MSDOS, ATARI, AMIGA, MTOS, NeXT, ultrix, VMS, _IBMR2, alliant
*
* Environmental variables are written as $(name).
* Commands are written as $`command`.
*/
[...]
#if defined(_Windows) !defined(FONTPATHSET)
# define FONTPATHSET
static const struct path_table fontpath_tbl[] =
{
{ $(windir)\\fonts },
/* Ghostscript */
{ c:\\gs\\fonts },
/* X11 */
{ $(CYGWIN_ROOT)\\usr\\X11R6\\lib\\X11\\fonts\\Type1 },
/* fpTeX */
{ $`kpsewhich -expand-path=$HOMETEXMF`\\fonts\\type1! },
{ $`kpsewhich -expand-path=$TEXMFLOCAL`\\fonts\\type1! },
{ $`kpsewhich -expand-path=$TEXMFMAIN`\\fonts\\type1! },
{ $`kpsewhich -expand-path=$TEXMFDIST`\\fonts\\type1! },
{ NULL }
};
#endif
[...]
/* Fallback: Should work for unix */
#ifndef FONTPATHSET
static const struct path_table fontpath_tbl[] =
{
/* teTeX or TeXLive */
{ $`kpsexpand '$HOMETEXMF'`/fonts/type1! },
{ $`kpsexpand '$TEXMFLOCAL'`/fonts/type1! },
{ $`kpsexpand '$TEXMFMAIN'`/fonts/type1! },
{ $`kpsexpand '$TEXMFDIST'`/fonts/type1! },
/* Linux paths */
{ /usr/X11R6/lib/X11/fonts/Type1 },
{ /usr/X11R6/lib/X11/fonts/truetype },
/* HP-UX */
{ /usr/lib/X11/fonts!},
/* Ghostscript */
{ /usr/share/ghostscript/fonts },
{ /usr/local/share/ghostscript/fonts },
{ NULL }
};
#endif
[...]
switch (action) {
case ACTION_CLEAR:
/* Clear fontpath, fall through to init */
FPRINTF((stderr, Clear fontpath\n));
free(fontpath);
fontpath = p = last = NULL;
/* HBB 2726: 'limit' has to be initialized to NULL, too! */
limit = NULL;
case ACTION_INIT:
/* Init fontpath from environment */
FPRINTF((stderr, Init fontpath from environment\n));
assert(fontpath == NULL);
if (!fontpath)
{
char *envlib = getenv(GNUPLOT_FONTPATH);
if (envlib) {
/* get paths from environment */
int len = strlen(envlib);
fontpath = gp_strdup(envlib);
/* point to end of fontpath */
last = fontpath + len;
/* convert all PATHSEPs to \0 */
PATHSEP_TO_NUL(fontpath);
}
#if defined(HAVE_DIRENT_H) || defined(_Windows)
else {
/* set hardcoded paths */
const struct path_table *curr_fontpath = fontpath_tbl;
[...]
in src/variable.c. The above is taken from a recent CVS checkout, but
the 4.0.0 sources for the current Cygwin package have similar lines.
So gnuplot is using kpsexpand to locate some font files.
It looks like there are a couple of options.
One is to set GNUPLOT_FONTPATH in the environment before calling
gnuplot.
Another is to make a wrapper kpsexpand that looks for the real version
and does nothing if the real version is not present:
#! /bin/sh
if [ -x /usr/bin/kpsexpand ]; then
exec /usr/bin/kspexpand $@
fi
(though you might want to add some comments about why this is needed).
If the real kpsexpand is not present, then chances are the font files
are not -either, so it should not matter that the corresponding
directories named in the fontpath are bogus. You could install the
wrapper script in one of the directories in Octave's DEFAULT_EXEC_PATH
(for example, /usr/lib/octave/2.1.72/exec/i686-pc-cygwin, where a
couple of other scripts are already installed), then it would only be
found by Octave and should not introduce any other conflicts.
jwe
--
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: octave-forge dependency?
On 6-Dec-2005, Christopher Faylor wrote: | On Tue, Dec 06, 2005 at 01:14:13AM -0500, John W. Eaton wrote: | On 6-Dec-2005, Charles Wilson wrote: | Why does package octave-forge depend on tetex-bin? As far as I can | tell, octave-forge contains .oct and .m files, and few text and info | files -- nothing there should need TeX. I use MikTeX so I don't want | to have cygwin-TeX installed, but this octave-forge dependency pulls in | the whole mess for no good reason... | | Octave uses makeinfo to format docstrings. | | makeinfo is in the texinfo package not the TeX package. Sorry, I answered a bit hastily. I don't see a reason for the octave-forge package to have a direct dependency on tetex-bin. But doesn't the texinfo package depend on tetex in some way? I guess not: @ texinfo sdesc: Documentation system for on-line information and printed output category: Text Doc requires: cygwin libiconv2 libintl3 libncurses8 _update-info-dir version: 4.8-1 install: release/texinfo/texinfo-4.8-1.tar.bz2 695242 41433bef576c2bccc7136ec6677f6457 source: release/texinfo/texinfo-4.8-1-src.tar.bz2 1474048 ae84f762aae32d3356cfd8639ff608f8 [prev] version: 4.7-2 install: release/texinfo/texinfo-4.7-2.tar.bz2 690192 b0b7a4d4fb51cfe3d1b8b7db85463d1f source: release/texinfo/texinfo-4.7-2-src.tar.bz2 1356848 5529d19c02bd71abc13479e3ebaa8325 though I'm not sure why it doesn't. Isn't TeX needed to make this package fully functional? jwe -- 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/
octave-forge dependency?
On 6-Dec-2005, Charles Wilson wrote: | Why does package octave-forge depend on tetex-bin? As far as I can | tell, octave-forge contains .oct and .m files, and few text and info | files -- nothing there should need TeX. I use MikTeX so I don't want to | have cygwin-TeX installed, but this octave-forge dependency pulls in the | whole mess for no good reason... Octave uses makeinfo to format docstrings. jwe -- 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/
Building libstdc++.dll the easy way
On 6-Oct-2005, Danny Smith wrote: | Building libstdc++.dll may be a hard problem for a mathematician or | for libtool, but this is how an ordinary person coud do it. | | dlltool --output-def libstdc++.def --export-all libstdc++.a | gcc -shared -olibstdc++.dll -Wl,--out-implib,libstdc++.dll.a \ | libstdc++.def libstdc++.a | | | The main problem after that is in getting rid of the need for auto-import of | data objects by marking header files appropiately. The other main problem after that is that the C++ ABI has been changing, so having only one version of the library would cause trouble. But maybe that is not as big a problem now as it was in the past? OTOH, surely there will be some changes to the library in the future, so it seems that it would be a good idea to be able to have multiple versions of libstdc++.dll.a installed simultaneously? Or is this not possible for some reason? jwe -- 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/
problem mixing C++ exceptions and setjmp/longjmp
I believe the following program should print
main: calling doit
doit: calling toit
toit: throwing exception
toit: caught exception, longjumping
doit: longjump landed, throwing exception
main: caught exception
but on the current Cygwin (updated today) using the 1.5.13-1
cygwin.dll and either gcc 3.3 or 3.4, it crashes with a segfault just
after printing the next to last line:
doit: longjump landed, throwing exception
I tried going back to 1.5.12, but that did not fix the problem.
Can anyone reproduce this problem?
This problem affects GNU Octave, as it uses this technique to handle
interrupts in code that is a mixture of C++, C, and Fortran. If
SIGINT arrives in a section of Octave code, the signal handler sets a
flag and then returns, letting Octave check the flag periodically. At
some safe location, an exception is thrown that will return control
to the top level of the main interpreter loop. If SIGINT arrives
inside some foreign code (say, readline, or some Fortran code) then
the signal handler jumps back to the location of the call to the
foreign code. At that point, an exception is thrown to get back to
the top level. I've not had problems with this approach until
recently when I upgraded my Cygwin installation. Now Ctrl-C at the
prompt causes a segfault. The program below is a distillation of the
key features of the Octave code, and shows the same problem.
Any clues?
Thanks,
jwe
--
www.octave.org | [EMAIL PROTECTED]
#include setjmp.h
#include iostream
jmp_buf context;
class
exception
{
// empty;
};
static void
toit (void)
{
try
{
std::cerr toit: throwing exception std::endl;
throw exception ();
}
catch (exception)
{
std::cerr toit: caught exception, longjumping std::endl;
longjmp (context, 1);
}
}
static void
doit (void)
{
if (setjmp (context) == 0)
{
std::cerr doit: calling toit std::endl;
toit ();
}
else
{
std::cerr doit: longjump landed, throwing exception std::endl;
throw exception ();
}
}
int
main (void)
{
try
{
std::cerr main: calling doit std::endl;
doit ();
}
catch (exception)
{
std::cerr main: caught exception std::endl;
}
return 0;
}
--
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/
Octave package for Cygwin
I would like to contribute a Cygwin package for GNU Octave (www.octave.org). To start, I propose two packages, one with the Octave interpreter, shared libraries, and other files necessary to run Octave and another with the the header files and scripts necessary to compile and link user-supplied C++, C, or Fortran code with Octave. Here are the setup.hint files that I currently have: @ octave sdesc: The GNU Octave language for numerical computations category: Math requires: cygwin less ncurses readline texinfo ldesc: The GNU Octave language for numerical computations Octave is a (mostly Matlab (R) compatible) high-level language, primarily intended for numerical computations. It provides a convenient command-line interface for solving linear and nonlinear problems numerically. @ octave-headers sdesc: Header files for the GNU Octave language category: Math requires: cygwin octave gcc ldesc: Header files for the GNU Octave language. This packages provides the include files needed to compile and link user-supplied code with GNU Octave. If you only write interpreted .m files, you do not need this package. Eventually I would like to also provide packages for ATLAS, LAPACK, BLAS, fftw, and libhdf5 so that these features can be used with Octave. Does anyone know whether there might be other people who are working on these packages or who might be interested in helping? Currently, modules that are dynamically linked with Octave are quite large, apparently because libstdc++ is not a shared library and large portions of it end up in each module. Is it possible that this will change and that the version of libstdc++ distributed with Cygwin will become a shared library instead? Sorry if this is a FAQ (if there have been previous discussions, I would appreciate knowing where I could find them). Comments or suggestions? Thanks, jwe -- www.octave.org www.che.wisc.edu/~jwe
Re: Building Octave-2.1.35 using Cygwin-1.3.3-2
On 4-Dec-2001, Billinghurst, David (CRTS) [EMAIL PROTECTED] wrote: | You wrote that you had problems compiling octave-2.1.35 on cygwin, due to a | missing definition of _rl_clear_screen. | | The problem is that _rl_clear_screen is private and is not exported in | cygreadline.dll. As you and I both found out, simply removing the leading | underscore is the Wrong Thing. | | There are a number of solutions to this problem, including: | a) building octave without readline support, | b) building your own dll with this symbol exported | c) using the static libreadline.a | d) finding a way to use rl_clear_screen | e) getting someone else to do (b) for you | | Option (a) is easy as there is a configure option for this. | | Option (c) is pretty easy. | Configure octave with CFLAGS='-DREADLINE_STATIC -O' | Change -lreadline to /usr/lib/libreadline.a in Makeconf | make | | The rest are left as an exercise. It's not quite as easy as that now, since the readline sources are no longer distributed with Octave. In any case, this problem is fixed in the current Octave sources (in CVS) and should not appear in the next snapshot. jwe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
