I am unable to read or import anything into an ivtools drawing editor.
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.
When I try importing (or opening) a postscript or an eps file in idraw it segfaults without warning.
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.
I tried exporting (or printing) graphics to a filter (by selecting the "to command" checkbox on the dialog box), but when I type in something like "xv -" it doesn't work.
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.
What other drawing editors are available like idraw and ivtools drawtool?
See Also: Vector Graphic Foundry Editor Page
What bugs have been fixed in idraw?
with ivtools-0.7.9 now backing out past the first vertex (left-click) will terminate the polygon drawing in all the ivtools drawing editors. a long-standing problem in graphics staying on the grid when drawn with gravity on. The integer nature of the mouse coordinates were not fully taken into consideration when constructing graphics after arbitrary panning and zooming of the viewer. a recently revealed problem in the maintenance of arrowhead graphics, that hadn't been a problem until recent compilers cleared up the semantics of an overloaded assignment operator. a bug in the management of the filechooser dialog box glyphs (the ones used for Open/Save/SaveAs), that caused a segfault with some compiler setups. a bug in the handling of un-openable files that caused a segfault with some compiler setups. a bug in generating the idraw format version warning message (see below). Others see "warning: drawing version 0 newer than idraw version 0" when they load my drawing into their copy of idraw.
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.
Others see "warning: drawing version 0 newer than idraw version 0" then a segfault when they load my drawing into their copy of idraw.
First off, read the previous FAQ entry to understand why the warning message isn't more helpful.
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.
I'm using RedHat 7.* and gcc-2.96, and I get all kinds of errors. How can this be?
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
When I run configure on Darwin (Mac OS X), I see "./configure: read-only variable: PWD [1845]". Should I be worried?
Not about PWD. The configure script ensures that the PWD environment variable is correctly set, and Darwin doesn't want this value reset, but there is no problem because it is already correct.
The absolute pathname used by the "make depend" pass is not the same as the ABSTOP pathname written to config/config.mk by the configure script.
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 ImakeFlags in config/site.def.NETBSD for an example.
I can't read or import anything, and I built ivtools with gcc-3.0.0 or gcc-2.95.3 bundled with libstdc++-v3.
Check out this patch for more details. No longer needed after ivtools-1.0.2 -- the workaround was to replace any rewind with close/open.
I run "make World" or "make Makefiles", and see an error message like this
Making Makefiles for in
/proj/ivtools-1.0/src/IV-common/
/bin/sh: test: argument expected
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.
How should CPU be set in config.mk for Solaris?
The CPU make variable should be set to SUN4 in config/config.mk by the configure script.
I just can't get ivtools built on anything but Linux or FreeBSD. What do I do?
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".
First, after any problem with the build process, be aware that you might have to restore the state of the source tree in one of three ways: 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.
Second, be aware that the "make World" might need both XCONFIGDIR and PWD arguments. This is often the case for users of Solaris or DEC Alpha, where the default shells do not support a PWD environment variable. See other workarounds for the PWD problem here. Third, be aware that the "make World" is relying on configuration files that are outside of the scope of ivtools, that are part of the commercial X distribution delivered on your system (i.e "sun.cf"). This can cause problems, especially with Solaris, when you are using /usr/ccs/bin/make instead of GNU make (read more here). You also might want to peruse these recently updated instructions specific to building Vectaport software on Solaris-2.6 Fourth, be aware the imake works best (in this context) with the gcc version of cpp (the C preprocessor), and has problems with the default cpp available on commercial Unix'es. Read how to work around this here. Finally, if you are going to be doing a lot of source based development with C++ and gcc, you might want to consider partitioning your hard disk and installing some variant of an open-source Unix available for your processor. The more-inclusive approach of the open-source Unix'es avoids a lot of problems and headaches, because there is no single company filtering what goes into the environment, and things that have built once somewhere tend to keep compiling on a free Unix. 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.
When are you going to have a configure script?
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. Do I need to restore the top-level Makefile from the tar file after a faulty start at configuring things?
Yes.
I'm getting compiler errors with gcc-2.7.* when I use -O.
There were unresolved problems with gcc optimization for Linux Elf and ivtools with gcc-2.7.2.
I get an "iostream.h: No such file or directory" when compiling ivtools
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/usr/include/g++, /usr/lib/g++-include or /usr/local/lib/g++-include.
I set "HasDynamicSharedLibraries" to NO (in config/gcc.def), and it didn't seem to work
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.
The makefiles are looking for source code under /proj/ivtools-1.0, but that is not where I put the source tree on my system.
IvToolsSrcRoot (in config/local.def) needs to be set to $(TOP) instead of /proj/ivtools-1.0 (or the absolute pathname where you installed the source tree).
What if I want to configure with --enable-use-rpath, but my copy of gcc is setup to use the Solaris linker, which expects -R instead of -rpath?
Before running configure, manually edit config/local.def and config/params.def to change all uses of -rpath to -R.
The GNU version of make doesn't understand a -w argument. What do we do?
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.
Our version of make doesn't understand the $(shell pwd) construct. What do we do?
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.
With gcc-2.8.* I get internal compiler errors with optimization enabled (-O) on InterViews/alloctbl.c, IV-X11/xfont.c, and IV-X11/xwindow.c.
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)"
"make World XCONFIGDIR=..." doesn't work because cpp can't find a file included from site.def.$CPU.
imake is fragile when used with other than gcc's version of cpp. Three suggestions:
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 ivtools-info@vectaport.com, as well as complete logs of the build process, and we'll do our best to help you resolve this problem.
I just installed gcc-2.8.1, and when I rebuild ivtools I see this:
/usr/include/g++/streambuf.h:392: warning: invalid type `void *' for default argument to `ios *'
You need to upgrade to libstdc++-2.8.1.* as well. After installing you may have to do some of these steps:
Change the definition of GPlusPlusIncludeDir in config/site.def.$CPU to point to where the include files were installed (i.e. "/usr/local/include/g++"). Move any older version of libg++ or libstdc++ include directory out of the way (i.e "mv /usr/include/g++ /usr/include/g++.old"). Do a "make clean;make Makefiles;make depend" Establish a symbolic link from /usr/include/g++ to /usr/local/include/g++ (or wherever you installed libstdc++). 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.
I just installed gcc-2.8.1, and when I rebuild ivtools I see this:
/tmp/cca09221.s: Assembler messages:
/tmp/cca09221.s:193: Error: invalid character (0x8) before first operand
You need to turn on optimization to work-around bugs in non-optimized compilation. Add these lines to ivtools-1.0/config/local.def:
/*
* What you need to turn on optimizing (a good idea)
*/ #undef TurnOnOptimizing
#define TurnOnOptimizing YES
And "make Makefiles;make clean;make". This will be included by default in ivtools-0.7.4.
Download
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 commenti:
Post a Comment