Do you think your version of ivtools was compiled with gcc-3.0? Or could it have been compiled with a gcc-2.95.3 that was bundled with an early copy of libstdc++-v3? Check out this faq entry for more details. Otherwise, read the other faq entries below.
idraw can't handle general PostScript or EPS files, only those specially formatted in the way that idraw writes out its own drawings. And since we strive to preserve idraw pretty much as it is (was), these segfaults have not been fixed (yet).
However, you can convert arbitrary PostScript to idraw's editable format with pstoedit. See http://www.ivtools.org/ivtools/idrawthings.html for other things you can do with idraw and the idraw PostScript format.
Since ivtools-0.6.12, ivtools drawtool (and the rest of the ivtools drawing editors) automatically detect an attempt to open or import arbitrary PostScript, and invoke pstoedit (if it can be found) to filter the input.
The way the export mechanism works is the exported or printed graphics are written to a temporary file, and the pathname of that temporary file is appended to the command line entered into the field editor at the top of the dialog box. So in this example, "xv" would work, but not "xv -".
Since ivtools-0.7.1, to be more explicit about this mechanism, the dialog boxes search for an embedded "%s" in the command line, and replace it with the temporary file name. If an actual stdin-accepting filter is what you want to use, a "<%s" would be required at the end of the command line. If no "%s" is found in the command line the temporary filename is appended to the end of the line like before.
See Also: Vector Graphic Foundry Editor Page
The idraw version format number was incremented from 10 to 11 with ivtools-0.6.7. The intent of this new version number was to add support for more of the features of PostScript (and X11) that can be generated by utilities like plotutils: floating-point line width, cap-styles, join-styles.
From ivtools-0.6.7 to ivtools-0.7.2 the only change in the idraw format was the addition of some calls to
closepath in the PostScript, to ensure ellipses and circles are closed. This change was embedded in the PostScript prologue of the idraw document, and the result can still be read by older versions of idraw.
But the change in version number is detected by older versions of idraw, and a warning is printed out. Problem is, there has always been a bug in the warning message output (floats were treated as ints), so you see the not-so-helpful message of "
warning: drawing version 0 newer than idraw version 0". This problem has been fixed since ivtools-0.6.7. This patch could be applied to any other distribution of InterViews to alleviate the problem in those copies of idraw.
Secondly, the document you gave them has more than just a different version number. It probably makes use of some sort of backward-incompatible extension to the format. From its inception the idraw format versioning system was designed to be forward- if not backward-compatible. Which means you can always read older documents with newer versions of idraw, but the opposite is not guaranteed (hence the warning message). Sometimes it works, sometimes it doesn't.
The idraw format version 11 introduced by ivtools-0.6.7 is the first new version number since the InterViews 3.1 tar file was published in 1993. But up until ivtools-0.7.3 nothing of a backward-incompatible nature had been done with the new format number. And with ivtools-0.7.3 most all uses of the format are still 100% backward compatible.
But now there is a chance that you might generate, using a yet-to-be released copy of plotutils or some other approach, a version 11 idraw PostScript document with non-integer floating point line widths. This is handled smoothly by the idraw of ivtools-0.7.3 (and will be handled smoothly by the rest of the drawing editors of ivtools come 0.7.4), but presenting a version 11 idraw format with non-integer line widths to any version of idraw prior to ivtools-0.6.7 will cause the above warning message to be printed, possibly followed by a segfault. Presenting a version 11 idraw format with non-integer line widths to any version of idraw from ivtools-0.6.7 to ivtools-0.7.2 will not generate a warning message or cause a segfault, but neither will the document be read in.
To clear up all this confusion, the forthcoming version of ivtools (0.7.4) will increment the idraw format version number once again, from 11 to 12, and it will be recommended that non-integer line widths not be used in conjunction with format version 11 (although there is some support for it). In that way users of an idraw from ivtools-0.6.7 (i.e. users of Debian 2.1) will be warned of a version incompatibility if there is one, given a hint why their document did not open in idraw.
The 7.* series of RedHat distributions incorporates a variant of the gcc compiler that was never approved by the gcc steering committee. A decision was made to skip this version, and migrate to gcc-3.* when it came out. This has been done, but RedHat is still shipping gcc-2.96 with it's distribution. The fix is to upgrade to gcc-3.* or downgrade to gcc-2.95.*. This problem only impacts RedHat 7.*. Any other free Unix you can name has avoided this problem. If you are committed to using gcc-2.96, here is a patch submitted by Murray Jensen that attempts to do this on Solaris: http://sourceforge.net/tracker/index.php?func=detail&aid=400986&group_id=275&atid=300275
There is a vulnerability in the "make Makefiles" pass (the use of imake), where absolute pathnames that incorporate predefined C symbols get these symbols expanded to another value. For example, most PC-based uses of gcc have
i386 defined to
1, so a path like
/usr/src/i386/ivtools-1.0 gets expanded to
/usr/src/1/ivtools-1.0. To check the set of pre-defined symbols, enter this command:
touch test.c;gcc -dM -E test.c.
You can either rename the affected directory in which ivtools resides, or you can add
-U undefine arguments as necessary to the imake command line. See the definition of
config/site.def.NETBSD for an example.
Looks like you need set the value of CPU in config/config.mk. The configure script should have written the value of "make CPU" in that file, i.e. "CPU = LINUX". Run "make CPU" again by hand to see what it should be. "grep ArchitectureName config/arch.defs" to get a complete list of supported operating systems.
Unique challenges are present for building ivtools on any commercial version of Unix, problems that just don't exist with open-source free software Unix'es. But don't despair, read through the following list of pointers and try again. It's only the build process that's frustrating. Once you get it built you'll find most of the code is very old and very stable on a wide variety of platforms.
Even before reading this list, see if you have CPU defined in config/config.mk. If you have no config/config.mk, do a ./configure. If it is undefined in config/config.mk, test what the value should be with "make CPU".
- 1) restore the top-level Makefile from either Makefile.bak or the tar file
- 2) do a "make clean" to remove the effects of previous compiles
- 3) completely erase and restore the source tree from the tar file, to be absolutely sure of starting from a known state.
Or consider switching to MacOS X with XFree86 4.2.0 available directly from Apple. ivtools now builds on Darwin (Mac OS X), as of version 1.0.2.
Since release 0.6.10 there is a configure script for ivtools tested on at least Linux, Solaris, and OSF-Alpha. Since there is no extensive use yet made of any machine specific information, this configure script should work for other OS'es with the creation of an appropriately named, empty config/$os-gcc.mk file (a whole set of these are incorporated since 0.6.11). Supported flags include:The configure script might also use the PWD environment variable to fix the base directory of the ivtools source tree for use in the ivmkmf script. You may have to set this manually prior to running the configure script if your shell does not support it. For more details see the INSTALL directions.
Make sure you have a copy of libstdc++ installed, like described in the ivtools INSTALL. This is a separate package from gcc. See if it exists on your system by looking for a directory like
Try adding APP_CCLDFLAGS = -static to each main.c's Imakefile that your are trying to static link. But if you are static linking more than a few you might want to stay with shared libraries because of the savings in disk, memory, and runtime.
It would seem that the Solaris configuration files for X Windows (openwindows) assumes the Solaris version of make, hence the incompatible -w. You can get by using the Solaris version of make, but need to be aware of the following FAQ entry. Pointed out by M. Rasit Eskicioglu of the University of Alberta.
In the top level Makefile you can define a symbol, PWDX, for the pwd command and change all occurrences of (shell pwd) to (PWDX:sh). Do this BEFORE running make World (or make Makefile). You need only to change the top-level Makefile. Submitted by Dan DeJohn of Digicomp.
Manually disable optimization for these modules by removing the "$(OPTIMIZE_CCFLAGS)" from the corresponding macro call in src/IV/Imakefile (then doing a "make Makefiles" and "make"). Leave the comma before "$(OPTIMIZE_CCFLAGS)"
First, after having any problem with "make World" be sure to restore the top-level Makefile from the tar file. Subsequent problems could be due to a corrupt top-level Makefile. You can verify this by looking at that Makefile directly.
Second, try and setup your environment so that your imake uses a GNU version of cpp. If you do a "gcc -v" you'll see the directory where the gcc specs are read from. The cpp you want is in the directory immediately above the specs directory.
Finally, if you have further problems, please forward copies of the afflicted files (the top-level Makefile, config/config-hpux-gcc.mk, etc..) to email@example.com, as well as complete logs of the build process, and we'll do our best to help you resolve this problem.
"make clean;make Makefiles;make depend"
You also will see this error whenever NULL gets redefined as "((void*) 0)" instead of "0", which is the way the C++ compiler likes it. Most, if not all, of these warnings were fixed by ivtools-0.7.4.
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog: