ivtools-user Mailing List for ivtools
Brought to you by:
johnston
Menu
▾
▴
ivtools-user
You can subscribe to this list here.
| 2000 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(12) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(6) |
Dec
(2) |
| 2002 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(8) |
| 2003 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rachel <se...@pu...> - 2003-05-21 15:38:11
|
Dear Sir or Madam,
I have the pleasure to know your esteemed corp.
We are a manufacturer & exporter of garments and bags in Quanzhou, China.
I think we can cooperate and supply you with garments as you need.
The following is some introductions about our company.
Set up: 1988
Type: manufacturer & exporter
Product: knitted garments and bags
Employees: 1300 persons ( garments factory: 500 bags factory: 800)
Product data:
product (main items) capacity(/year)
brief 2,000,000dzs
baby body 1,800,000dzs
boxer short 200,000dzs
pajama 50,000dzs
soft bag 1,500,000pcs
hard bag 500,000pcs
Mimn order: 300dzs for garments
Payment: irrevocable L/C at sight
Bank: BANK OF CHINA
Our garment factory mainly specialize in Lady's and men's underwear,
children's wear, baby's wear, pajama, boxer shorts, T-shirt, etc.
The materials we often use are cotton, T/C, Polyester, Polyamide,
Elasthan, and Polyamide. Our products are design with PAD system,
produced with advanced equipment, processed in highly quality control
system with seasoned workmanship and high efficiency. Our main market
is Europe, Australia, Japan and America. We also accept the orders designed
and required by costumers. You can see some pictures of our samples through
our web http://www.senwer.com. (For more pictures in your interesting,
pls kindly contact us directly).
Our bag factory was founded in 1988, too. We produce all kinds of bags,
including suitcase, backpack, travel bag, shoulder bag, sport bag, trolley,
camera bag, tote bag, school bag, computer case, luggage,waist bag, notecase, etc.
And the goods have met a great favor in the Europe countries, Australia
and America because of their good quality, beautiful design and competitive price.
Thank you very much. Hope you will give us an opportunity to do
business together and we will try our level best to fulfill your present
requirement. Should you therefore need any more details for your
clarification, pls do not hesitate to contact us. And you are welcome
to visit our factories.
With best regards
Rachel Wang
Mob:0086-13960286700
E-mail:ra...@se...
Jason Chen
Mob:0086-13959893400
E-mail: jas...@se...
Vicki Wang
Mob:0086-13960228599
E-mail: vi...@se...
-----------------------------------------------------------------------------
SENWER GARMENTS CO., LTD.
ADD: Room F202, Fugui Renjia Building, Liuguan Road, Quanzhou, Fujian, China.
Tel: 0086-595-2506700 Fax: 0086-595-2563400 P.C.:362000
Http://www.senwer.com E-mail: se...@pu...
-----------------------------------------------------------------------------
|
|
From: Scott J. <joh...@ve...> - 2003-01-24 20:25:49
|
I had no idea idraw/Unidraw was using a temp file to implement that capability (and I've been studying this source for ten years). You clearly showed me a hole in my knowledge. That said, this is something that has worked without problem (and without any changes to the source code) for as long as I can remember. I have a suspicion it is due to a change in behavior of the iostreams capability, the most volatile component. But it would take time to prove this, and to figure out a workaround. Time I don't have at the moment, and I doubt you'll find any volunteers on this mailing list to do it for you. So you have two options. Either figure out how to fix it yourself, then submit any relevant patch, and I'll make sure to include it in the next release of ivtools. You seem to have a good start on understanding the problem. Perhaps this is useful learning activity for you. Or enter it as a bug or support request at the ivtools SourceForge project page (http://sf.net/projects/ivools), so we have a record of it for future reference. Scott p.s. I would be curious if you have same problem using ivtools drawtool. >Hi Scott, > >Thanks for your reply. >More details about the ivtools problem. > >I am using idraw. I figured out that everytime I do a simple "group" of two >lines and then "duplicate" the group, there is an error message "Unidraw >error: couldn't copy object (/tmp unwritable?)", which comes from >Catalog::RetrieveObject in src/Unidraw/catalog.c. The function will create a >tmp file in /tmp, and write something in. > >Then I traced into the source code. In Catalog::RetrieveObject, ReadObject >will be called. I checked in.good() of the istream(in) that corrsponds to >the filebuf of the tmp file (something like /tmp/.udcpAAA4dayEO) in a couple >of places in the funcition, and then found that >Catalog::ReadBgfilled() >is the place where in.good() turns 0. > >The tmp files is as follows: >--------------------------------------------------------------------- >%I Unidraw 1 >%I 9025 661760 0 2 > >%I 1002 256976 9030 %END_ARROWLINE_COMP% 77 305 122 306 >%I 1 >%I c Black 0 0 0 >%I c White 1 1 1 >%I b 65535 0 >%I t 1 -0 -0 1 143 183 0 0 1 >%I p n %END_ARROWLINE_COMP% > >%I 1002 643920 9030 %END_ARROWLINE_COMP% 90 320 132 294 >%I 1 >%I c Black 0 0 0 >%I c White 1 1 1 >%I b 65535 0 >%I t 1 -0 -0 1 143 183 0 0 1 >%I p n %END_ARROWLINE_COMP% > >%I 4294967295 >%I b ~ (the line was read by ReadBgFilled, and in<<bgFilled will return a >value other than 0 and 1) >%I c ~ >%I c ~ >%I f ~ >%I p ~ >%I t ~ >%I 0 >%I 0 >---------------------------------------------------------------------------- >------- > >The function ReadBgFilled should read the second line of each section in the >temp file (%I 1) and set the variable bgFilled to 0 or 1. >For some reason, the ReadBgFilled will set bgFilled to a value of 149168, >after two correct ReadBgfilled() for those two lines that need to be grouped >and duplicated. Note that bgFilled is a boolean type variable. Since the >first two ReadBgFilled call were OK, I guess the incorrect value of bgFilled >comes from the line "%I b ~" in the last section (%I 4294967295). It expects >a 1 or 0 but there is b in the tmp file. > >Question: Why do we need the tmp file? What is the last section of the tmp >file for? >I suspect that the last section is correctly done(look at %I 4294967295).... >There are only 2 exist components (lines) that need to be duplicated, so >maybe the last section should not be there, and Catalog::ReadObject should >only call ReadBgFilled twice......... > >Any idea? > >Thanks! > >-Pei |
|
From: Scott J. <joh...@ve...> - 2003-01-24 17:16:04
|
At 8:20 PM -0500 1/22/03, Pei Zheng wrote: >Hi, >I have downloaded ivtools 1.0 and built it on Solaris 8. No specific >configuration options except a prefix. Everything seems fine. But when I run >the program and duplicate some objects, I got errors that look like "/tmp >unwritable". Clearly my /tmp is writable. Sometimes after a duplication >operation, the program will crash right away. Kind of memory access or seg >fault problem. > >Any idea? > >Thanks! > >-Pei > This problems seems somewhat unrelated to ivtools. Nothing is written to /tmp (or any other file) while simply editing a document. Except for swap space, which you may have set up on /tmp. Then you could be running out of virtual memory, which could cause a crash. Are you familiar with the use of gdb? This will be necessary if you want to dig further into the problem. Run the program you are using (you didn't say which) through gdb through emacs, and you can find out where the crash occurs. Scott Johnston |
|
From: Scott J. <joh...@ve...> - 2003-01-24 08:11:02
|
You will need to study how one of the example programs (under
src/glyphs) gets compiled and linked. You need to link against at
least both libX11 and libstdc++ as well as libIV. Good luck.
Scott Johnston
At 3:12 AM +0000 1/23/03, Eliz .. wrote:
>Dear Sir,
>
>I am a student currently very new on InterViews. I have install
>Ivtools 1.0.7 under redhat linux. Currently i am trying to compiling
>the a simple "hi mom" example as show below
>
>#include<InterViews/session.h>
>
>#include<InterViews/backgroung.h>
>
>#include<InterViews/window.h>
>
>#include<IV-looks/kit.h>
>
>int main(int argc, char** argv) {
> Session* session = new Session("Himom", argc, argv);
> WidgetKit& kit = *WidgetKit::instance();
> return session->run_window(
> new ApplicationWindow(
> new Background(
> kit.label("hi mom!"), kit.background()
> )
> )
> );
> }
>
>
>i have compile using the command belows
>
> > gcc filename.c -lIV
>
>and the follows error shown:
>
>/usr/local/lib/libIV.so:underfined reference to
>`isstream::operator>>(short &)'
>/usr/local/lib/libIV.so:underfined reference to 'XshmQueryVersion'
>/usr/local/lib/libIV.so:underfined reference to 'XSetFunction'
>/usr/local/lib/libIV.so:underfined reference to 'XFlush'
> .........
> .........
> .........
> .........
>
>/usr/local/lib/libIV.so:underfined reference to 'XMapRaised'
>
> Is it because i compile it in a wrong way?
>
>
>
>Thanks a lot
>
>Eliz
>
>
>
>MSN 8 helps <http://g.msn.com/8HMLEN/2752>ELIMINATE E-MAIL VIRUSES.
>Get 2 months FREE*.
>------------------------------------------------------- This SF.net
>email is sponsored by: Scholarships for Techies! Can't afford IT
>training? All 2003 ictp students receive scholarships. Get hands-on
>training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
>www.ictp.com/training/sourceforge.asp
>_______________________________________________ Ivtools-user mailing
>list Ivt...@li...
>https://lists.sourceforge.net/lists/listinfo/ivtools-user
|
|
From: Eliz .. <s1...@ho...> - 2003-01-23 03:12:11
|
<html><div style='background-color:'><P><BR>Dear Sir,</P>
<P>I am a student currently very new on InterViews. I have install Ivtools 1.0.7 under redhat linux. Currently i am trying to compiling the a simple "hi mom" example as show below</P>
<P>#include<InterViews/session.h></P>
<P>#include<InterViews/backgroung.h></P>
<P>#include<InterViews/window.h></P>
<P>#include<IV-looks/kit.h></P>
<P>int main(int argc, char** argv) {<BR> Session* session = new Session("Himom", argc, argv);<BR> WidgetKit& kit = *WidgetKit::instance();<BR> return session->run_window(<BR> new ApplicationWindow(<BR> new Background(<BR> kit.label("hi mom!"), kit.background()<BR> )<BR> )<BR> );<BR> }<BR> </P>
<P>i have compile using the command belows</P>
<P>> gcc filename.c -lIV</P>
<P>and the follows error shown:</P>
<P>/usr/local/lib/libIV.so:underfined reference to `isstream::operator>>(short &)'<BR>/usr/local/lib/libIV.so:underfined reference to 'XshmQueryVersion'<BR>/usr/local/lib/libIV.so:underfined reference to 'XSetFunction'<BR>/usr/local/lib/libIV.so:underfined reference to 'XFlush'<BR> .........<BR> .........<BR> .........<BR> .........</P>
<P>/usr/local/lib/libIV.so:underfined reference to 'XMapRaised' </P>
<P> Is it because i compile it in a wrong way? </P>
<P> </P>
<P>Thanks a lot</P>
<P>Eliz</P></div><br clear=all><hr>MSN 8 helps <a href="http://g.msn.com/8HMLEN/2752">ELIMINATE E-MAIL VIRUSES.</a> Get 2 months FREE*.</html>
|
|
From: Pei Z. <zhe...@cs...> - 2003-01-23 01:21:14
|
Hi, I have downloaded ivtools 1.0 and built it on Solaris 8. No specific configuration options except a prefix. Everything seems fine. But when I run the program and duplicate some objects, I got errors that look like "/tmp unwritable". Clearly my /tmp is writable. Sometimes after a duplication operation, the program will crash right away. Kind of memory access or seg fault problem. Any idea? Thanks! -Pei |
|
From: Scott J. <joh...@ve...> - 2002-12-19 16:57:10
|
Michael, Now I understand the problem. You showed that __gxx_personality_v0 is referenced from every C++ object file in libIV, and defined in the libstdc++ libraries under /usr/lib/gcc-lib/i386-redhat-linux/2.96/. However with "ldd -r" you showed that you are using /usr/lib/libstdc++-libc6.2-2.so.3 instead, which does not define the __gxx_personality_v0 symbol. This is definitely a C++ library vulnerability introduced by RedHat 7.3. Maybe there is a RedHat FAQ with suggestions on the best workaround. Usually gcc system libraries like libstdc++ and libc are determined at compile time. libstdc++ is a special case, and I can't really say how gcc-2.96 deals with it. You could try explicitly putting /usr/lib/gcc-lib/i386-redhat-linux/2.96/lib in your LD_LIBRARY_PATH environment variable. Or you could investigate how the original linking of idraw went, by adding a -v to the command line that links idraw, and studying the intermediate command lines. Did it really link against /usr/lib/libstdc++-libc6.2-2.so.3 and not catch the missing symbol at link time? Scott Johnston http://www.ivtools.org |
|
From: Michael P. () <pr...@ma...> - 2002-12-19 03:38:30
|
On Wed, 18 Dec 2002, Scott Johnston wrote:
> Date: Wed, 18 Dec 2002 18:27:30 -0800
> From: Scott Johnston <joh...@ve...>
> To: pr...@ma...
> Cc: ivt...@li...
> Subject: Re: question about installation
>
> Ok, when searching through libraries to find where
> __gxx_personality_v0 is defined, you need to adjust the grep to be
> this:
>
> grep -l "T __gxx_personality_v0"
>
> This will isolate the library it is defined in (as opposed to
> libraries where it is an unresolved reference).
>
> The src/IV/LINUX I was referring to was in the ivtools-1.0 source
> tree (i.e. ivtools-1.0/src/IV/LINUX).
OK:
I went to /usr/lib and did
for x in `find . -name \*.a -print`
> do
> echo $x
> nm $x | grep -l "T __gxx_personality_v0"
> done
and this turned up nothing.
I did the same in /usr/lib/gcc-lib/i386-redhat-linux/2.96/ and
got
./libgcc.a
./libg2c.a
./libobjc.a
./libstdc++.a
and changing to \*.so\* got
./libobjc.so.1
./libobjc.so
./libobjc.so.1.0.0
./libstdc++.so
Going to src/IV/LINUX, I did
for x in *.o
> do
> echo $x
> nm $x | grep gxx_personality_v0
> done
and got many lines, begining with:
action.o
adjuster2_6.o
adjust.o
aggr.o
align.o
alloctbl.o
arrcomp.o
background.o
banner.o
bevel.o
border2_6.o
border.o
box2_6.o
box.o
browser.o
button2_6.o
button.o
character.o
compeditor.o
composition.o
compositor.o
control.o
...
and ending with:
...
xdrag.o
xevent2_6.o
xevent.o
xfont.o
xinter.o
xpainter.o
xpattern.o
xraster.o
xreqerr.o
xselection.o
xwindow.o
xymarker.o
Mike
--
Michael Prophet pr...@ma...
Department of Mathematics 319-273-2104
University of Northern Iowa
Cedar Falls, IA 50614-0506
|
|
From: Scott J. <joh...@ve...> - 2002-12-19 02:27:04
|
Ok, when searching through libraries to find where __gxx_personality_v0 is defined, you need to adjust the grep to be this: grep -l "T __gxx_personality_v0" This will isolate the library it is defined in (as opposed to libraries where it is an unresolved reference). The src/IV/LINUX I was referring to was in the ivtools-1.0 source tree (i.e. ivtools-1.0/src/IV/LINUX). Scott Johnston http://www.ivtools.org |
|
From: Michael P. () <pr...@ma...> - 2002-12-18 21:13:13
|
On Wed, 18 Dec 2002, Scott Johnston wrote:
> Date: Wed, 18 Dec 2002 12:05:36 -0800
> From: Scott Johnston <joh...@ve...>
> To: pr...@ma..., ivt...@li...
> Subject: Re: question about installation
>
> At 1:24 PM -0600 12/18/02, Michael Prophet () wrote:
> >On a machine running Linux version 2.4.18-18.7.x, Redhat 7.3, I tried to
> >install idraw using ivtools-1.0.7.tgz. Following the INSTALL instructions
> >I did the usual
> > ./configure
> > make
> > su -c "make install"
> >
> >and everything seemed to go ok but when I run idraw I get the error:
> >"/usr/local/bin/idraw: relocation error: /usr/lib/libIV.so: undefined
> >symbol: __gxx_personality_v0"
> >
> >any suggestions?
> >
> >Mike
> >
Scott,
thanx for the help - keep in mind I know only basic linux user stuff
(enough to screw things up but not fix them...)
> I assume you are using gcc-2.96. For a long time I avoided making
> ivtools compile with that version of gcc, which was never approved by
> the gcc steering committee, and is only distributed by RedHat. But
> recently I fixed the compile problems as you've demonstrated,
> without, I guess, resolving all the run-time resolution of symbols.
>
> The easiest thing to do might be to upgrade to a gcc-3.* compiler.
> Otherwise we can engage in a search mission to discover why
> __gxx_personality_v0 is referenced by libIV but not resolved from any
> linked library.
yes - I'm using gcc-2.96. I tried to upgrade to gcc-3* (via .rpm) but this
seems to require a lot of additional upgrades, so...
> The usual reason is __gxx_personality_v0 is defined in a system
> include file (a gcc system include file, given the name), yet is not
> compiled into a system library (at least the ones you are resolving
> given your use of ldconfig and the LD_LIBRARY_PATH environment
> variable). You can look in a few places for that symbol, either
> /usr/include or the directory revealed when you type "gcc -v". Use
> the find command like so:
>
> # first cd to the pertinent directory
> find . -type f -exec grep -l gxx_personality_v0 {} \;
I did the find in
/usr/include
as well
/usr/lib/gcc-lib/i386-redhat-linux/2.96/
but nothing turned up
> That should find where the symbol is hiding. Other possibilities are
> the symbol is automatically inserted into the object code by the
> compiler. To get an idea of where the symbol is referenced from
> libIV, try this (assuming use of sh or bash):
>
> cd src/IV/LINUX
> for x in *.o
> > do
> > echo $x
> > nm $x | grep gxx_personality_v0
> > done
I went to /usr/src but did not find IV/linux so I didn't really know what
to do here.
> Now armed with this information, you probably want to determine if a)
> that symbol is nowhere to be found in a system library, or b) that
> symbol exists in a system library, but you are not linking that
> library. To search for libraries, go to /usr/lib and that directory
> revealed by "gcc -v" and try this:
>
>
> for x in `find . -name \*.a -print`
> > do
> > echo $x
> > nm $x | grep gxx_personality_v0
> > done
I did the above in directory revealed by gcc -v and found
/libgcc.a
./libg2c.a
./libobjc.a
./libstdc++.a
and then
/libobjc.so.1
./libobjc.so
./libobjc.so.1.0.0
./libstdc++.so
I repeated this in /usr/lib and got tons of lines of output.
> and repeat for \*.so\* (instead of \*a) to search the dynamic
> libraries as well. That should give you some idea of whether the
> symbol is out there. If it is, study your current set of dynamically
> linked libraries with the use of "ldd -r" on your executable.
I had never used the -r option before with ldd...this is what happended:
[root@banach root]# ldd -r /usr/local/bin/idraw
libUniIdraw.so => /usr/lib/libUniIdraw.so (0x4002c000)
libUnidraw.so => /usr/lib/libUnidraw.so (0x40083000)
libIV.so => /usr/lib/libIV.so (0x401d2000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x403ba000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x403c7000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x4049c000)
libm.so.6 => /lib/libm.so.6 (0x404df000)
libc.so.6 => /lib/libc.so.6 (0x40501000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40628000)
libdl.so.2 => /lib/libdl.so.2 (0x4062f000)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __gxx_personality_v0 (/usr/lib/libIV.so)
undefined symbol: __cxa_pure_virtual (/usr/lib/libIV.so)
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE
(/usr/lib/libIV.so)
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE
(/usr/lib/libIV.so)
undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE
(/usr/lib/libIV.so)
undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE
(/usr/lib/libIV.so)
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE
(/usr/lib/libIV.so)
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE
(/usr/lib/libIV.so)
.
.
.
These lines repeated hundreds of times...tons of "undefined symbol:"
descriptions...many lines were repeated often....near the end of the
output the lines were:
undefined symbol: _ZNSt8ios_base6badbitE (/usr/lib/libUniIdraw.so)
undefined symbol: _ZSt4cerr (/usr/lib/libUniIdraw.so)
undefined symbol: _ZNSt5ctypeIcE2idE (/usr/lib/libUniIdraw.so)
undefined symbol: _ZNSt8ios_base7goodbitE (/usr/lib/libUniIdraw.so)
undefined symbol: _ZNSt7codecvtIcc9mbstate_tE2idE
(/usr/lib/libUniIdraw.so)
undefined symbol: _Znaj (/usr/lib/libUniIdraw.so)
undefined symbol: __cxa_rethrow (/usr/lib/libUniIdraw.so)
undefined symbol: _ZNSt6localeC1ERKS_ (/usr/lib/libUniIdraw.so)
undefined symbol: _ZSt18uncaught_exceptionv (/usr/lib/libUniIdraw.so)
undefined symbol: _ZNSt8ios_base13_M_grow_wordsEi
(/usr/lib/libUniIdraw.so)
undefined symbol: _ZSt19__throw_ios_failurePKc (/usr/lib/libUniIdraw.so)
What's the next step?
Mike
--
Michael Prophet pr...@ma...
Department of Mathematics 319-273-2104
University of Northern Iowa
Cedar Falls, IA 50614-0506
|
|
From: Scott J. <joh...@ve...> - 2002-12-18 20:05:16
|
At 1:24 PM -0600 12/18/02, Michael Prophet () wrote:
>On a machine running Linux version 2.4.18-18.7.x, Redhat 7.3, I tried to
>install idraw using ivtools-1.0.7.tgz. Following the INSTALL instructions
>I did the usual
> ./configure
> make
> su -c "make install"
>
>and everything seemed to go ok but when I run idraw I get the error:
>"/usr/local/bin/idraw: relocation error: /usr/lib/libIV.so: undefined
>symbol: __gxx_personality_v0"
>
>any suggestions?
>
>Mike
>
I assume you are using gcc-2.96. For a long time I avoided making
ivtools compile with that version of gcc, which was never approved by
the gcc steering committee, and is only distributed by RedHat. But
recently I fixed the compile problems as you've demonstrated,
without, I guess, resolving all the run-time resolution of symbols.
The easiest thing to do might be to upgrade to a gcc-3.* compiler.
Otherwise we can engage in a search mission to discover why
__gxx_personality_v0 is referenced by libIV but not resolved from any
linked library.
The usual reason is __gxx_personality_v0 is defined in a system
include file (a gcc system include file, given the name), yet is not
compiled into a system library (at least the ones you are resolving
given your use of ldconfig and the LD_LIBRARY_PATH environment
variable). You can look in a few places for that symbol, either
/usr/include or the directory revealed when you type "gcc -v". Use
the find command like so:
# first cd to the pertinent directory
find . -type f -exec grep -l gxx_personality_v0 {} \;
That should find where the symbol is hiding. Other possibilities are
the symbol is automatically inserted into the object code by the
compiler. To get an idea of where the symbol is referenced from
libIV, try this (assuming use of sh or bash):
cd src/IV/LINUX
for x in *.o
> do
> echo $x
> nm $x | grep gxx_personality_v0
> done
Now armed with this information, you probably want to determine if a)
that symbol is nowhere to be found in a system library, or b) that
symbol exists in a system library, but you are not linking that
library. To search for libraries, go to /usr/lib and that directory
revealed by "gcc -v" and try this:
for x in `find . -name \*.a -print`
> do
> echo $x
> nm $x | grep gxx_personality_v0
> done
and repeat for \*.so\* (instead of \*a) to search the dynamic
libraries as well. That should give you some idea of whether the
symbol is out there. If it is, study your current set of dynamically
linked libraries with the use of "ldd -r" on your executable. If it
isn't you'll need to go the original source file which references
that symbol and recompile it with the -E argument, then study the
output of the preprocessor to see what include file inserted it.
Then consult back here for advice on how to solve it.
These are the secrets to resolving loss of run-time symbols, a handy
tool when keeping up with RedHat :-) Happy Holidays.
Scott Johnston
http://www.ivtools.org
|
|
From: Michael P. () <pr...@ma...> - 2002-12-18 19:24:53
|
On a machine running Linux version 2.4.18-18.7.x, Redhat 7.3, I tried to install idraw using ivtools-1.0.7.tgz. Following the INSTALL instructions I did the usual ./configure make su -c "make install" and everything seemed to go ok but when I run idraw I get the error: "/usr/local/bin/idraw: relocation error: /usr/lib/libIV.so: undefined symbol: __gxx_personality_v0" any suggestions? Mike |
|
From: Scott J. <joh...@ve...> - 2002-12-02 20:01:22
|
I see that you are building a custom application on top of ivtools. That is great. First off, what sample program from ivtools did you start with for your "ged" program? Trying to make use of ivtools/InterViews without reusing an existing program is quite impossible. You need to start with a working program, and evolve it one step at a time into what you need, testing that things still work after every change. If that is the case, then when you get a segmentation fault in gdb you need to determine what caused it by inspecting (printing) all the local variables. This is made easier if you run gdb from emacs (M-x gdb). If everything is compiled with -g, and emacs can find the sources, it will bring up the source file and show where the segmentation fault occurred. There are so many possible explanations for what your problem might be that I can do little but offer strategies for you to apply yourself. I am not sure of your general skill level with C++ or Unix or gcc, but your problem might well fall into the category of basic skills needed for these domains. I would suggest a book on programming for Linux, one with an emphasis on C++, gcc, and gdb. Unfortunately I can't recommend any titles (please share with the list if you find a good one). But if the problem is specific to ivtools, please post further to this mailing list for continued help. Good Luck, Scott Johnston http://www.ivtools.org At 1:40 PM -0500 12/2/02, czebaduag wrote: > Hiiii... > >I continue trying to find solution about an application >with ivtools 1.0.6.... > >Next I give you my error message: > >gdb ./LINUX_EGCS/ged >GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) >Copyright 2001 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public >License, and you are >welcome to change it and/or distribute copies of it under >certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show >warranty" for details. >This GDB was configured as "i386-redhat-linux"... >(gdb) run >Starting program: >/home/setac/Head/SetacC/Ged/ged/./LINUX_EGCS/ged >[New Thread 1024 (LWP 6031)] >Conectado a SQL como modelos > > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 1024 (LWP 6031)] >0x40705b1f in rep__C7ivColorP14ivWindowVisual >(this=0x812a6c8, wv=0x8124300) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcolor.c:39 >39 implementPtrList(ColorRepList,ColorRep) >Current language: auto; currently c > > >#0 0x40705b1f in rep__C7ivColorP14ivWindowVisual >(this=0x812a6c8, > wv=0x8124300) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcolor.c:39 >#1 0x407037f5 in color__11ivCanvasRepPC7ivColor >(this=0x8141b00, > color=0x812a6c8) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcanvas.c:1282 >#2 0x40700d0f in fill__8ivCanvasPC7ivColor >(this=0x8141af0, color=0x812a6c8) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcanvas.c:500 >#3 0x4070421a in fill_rect__8ivCanvasffffPC7ivColor >(this=0x8141af0, l=0, > b=0, r=502.079987, t=382.079987, c=0x812a6c8) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcanvas.c:518 >#4 0x4066313b in >draw__C12ivBackgroundP8ivCanvasRC12ivAllocation ( > this=0x8126fc0, c=0x8141af0, a=@0x8141a38) > at >/home/setac/ivtools/ivtools-1.0/src/include/InterViews/geometry.h:295 >#5 0x4071d805 in repair__8ivWindow (this=0x81419e8) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xwindow.c:581 >#6 0x4071c834 in repair__9ivDisplay (this=0x8123700) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xwindow.c:1765 >#7 0x4071c9b6 in get__9ivDisplayR7ivEvent >(this=0x8123700, event=@0xbffff470) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xwindow.c:2018 >#8 0x406c309c in check__12ivSessionRepR7ivEvent >(this=0x80fe2f8, > e=@0xbffff470) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:3 >---Type <return> to continue, or q <return> to quit--- >80 >#9 0x406c2f6f in read__9ivSessionR7ivEventPFv_Ui >(this=0x80f15d0, > e=@0xbffff470, test=0) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:3 >45 >#10 0x406c2d5b in run__9ivSession (this=0x80f15d0) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:2 >85 >#11 0x406c2e0d in run_window__9ivSessionP8ivWindow >(this=0x80f15d0, > w=0x81419e8) > at >/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:2 >97 >#12 0x080536fd in main (argc=1, argv=0xbffff684) at >ged.cc:86 >#13 0x4139a507 in __libc_start_main (main=0x80535ac ><main>, argc=1, > ubp_av=0xbffff684, init=0x8051cd8 <_init>, >fini=0x809b8c0 <_fini>, > rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff67c) > at ../sysdeps/generic/libc-start.c:129 > > >can everybody help me......???? > >I don know what hapened..... > > >Thanks a lot for your time....... > > >Carlos Zebadua > > >------------------------------------------------------- >This SF.net email is sponsored by: Get the new Palm Tungsten T >handheld. Power & Color in a compact size! >http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en >_______________________________________________ >Ivtools-user mailing list >Ivt...@li... >https://lists.sourceforge.net/lists/listinfo/ivtools-user |
|
From: czebaduag <cze...@Pr...> - 2002-12-02 19:43:48
|
Hiiii...
I continue trying to find solution about an application
with ivtools 1.0.6....
Next I give you my error message:
gdb ./LINUX_EGCS/ged
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program:
/home/setac/Head/SetacC/Ged/ged/./LINUX_EGCS/ged
[New Thread 1024 (LWP 6031)]
Conectado a SQL como modelos
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 6031)]
0x40705b1f in rep__C7ivColorP14ivWindowVisual
(this=0x812a6c8, wv=0x8124300)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcolor.c:39
39 implementPtrList(ColorRepList,ColorRep)
Current language: auto; currently c
#0 0x40705b1f in rep__C7ivColorP14ivWindowVisual
(this=0x812a6c8,
wv=0x8124300)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcolor.c:39
#1 0x407037f5 in color__11ivCanvasRepPC7ivColor
(this=0x8141b00,
color=0x812a6c8)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcanvas.c:1282
#2 0x40700d0f in fill__8ivCanvasPC7ivColor
(this=0x8141af0, color=0x812a6c8)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcanvas.c:500
#3 0x4070421a in fill_rect__8ivCanvasffffPC7ivColor
(this=0x8141af0, l=0,
b=0, r=502.079987, t=382.079987, c=0x812a6c8)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xcanvas.c:518
#4 0x4066313b in
draw__C12ivBackgroundP8ivCanvasRC12ivAllocation (
this=0x8126fc0, c=0x8141af0, a=@0x8141a38)
at
/home/setac/ivtools/ivtools-1.0/src/include/InterViews/geometry.h:295
#5 0x4071d805 in repair__8ivWindow (this=0x81419e8)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xwindow.c:581
#6 0x4071c834 in repair__9ivDisplay (this=0x8123700)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xwindow.c:1765
#7 0x4071c9b6 in get__9ivDisplayR7ivEvent
(this=0x8123700, event=@0xbffff470)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../IV-X11/xwindow.c:2018
#8 0x406c309c in check__12ivSessionRepR7ivEvent
(this=0x80fe2f8,
e=@0xbffff470)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:3
---Type <return> to continue, or q <return> to quit---
80
#9 0x406c2f6f in read__9ivSessionR7ivEventPFv_Ui
(this=0x80f15d0,
e=@0xbffff470, test=0)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:3
45
#10 0x406c2d5b in run__9ivSession (this=0x80f15d0)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:2
85
#11 0x406c2e0d in run_window__9ivSessionP8ivWindow
(this=0x80f15d0,
w=0x81419e8)
at
/home/setac/ivtools/ivtools-1.0/src/IV/LINUX/../../InterViews/session.c:2
97
#12 0x080536fd in main (argc=1, argv=0xbffff684) at
ged.cc:86
#13 0x4139a507 in __libc_start_main (main=0x80535ac
<main>, argc=1,
ubp_av=0xbffff684, init=0x8051cd8 <_init>,
fini=0x809b8c0 <_fini>,
rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff67c)
at ../sysdeps/generic/libc-start.c:129
can everybody help me......????
I don know what hapened.....
Thanks a lot for your time.......
Carlos Zebadua
|
|
From: Scott J. <joh...@ve...> - 2002-11-26 18:42:49
|
At 12:15 PM -0600 11/26/02, Carlos Zebad=FAa wrote: >Hello... > > >I have installed ivtools 1.0.6 in Redhat 7.2, gcc 2.96..... > >There are no errors with this, but there are in my applications...... > >When I make (compilation) my application there are no errors....... > >but when I tryed to run it, I obtain next error: > > SIGSEV: violacion de segmento....... > > >I update gcc by page Redhat.com ...... > >I do not what happend...... > >Does anybody can help me??? > >Please > >Thanks a lot... > >Carlos Zebadua Carlos, I'm glad the build went smoothly with gcc-2.96 on RedHat 7.2 What application are you trying to run? drawtool? idraw? Have you tested to see if all your shared libraries are being found at run-time? You can use the "ldd -r" command to do this, i.e.: ldd -r ivtools-1.0/src/drawtool/LINUX/a.out or if you've installed it under /usr/local/bin: ldd -r /usr/local/bin/drawtool You might need to add a directory to your LD_LIBRARY_PATH environment variable, i.e.: export LD_LIBRARY_PATH=3D/usr/local/lib:$LD_LIBRARY_PATH Please provide further information if this does not fix the problem. Scott Johnston http://www.ivtools.org |
|
From: <cze...@pr...> - 2002-11-26 18:18:33
|
Hello... I have installed ivtools 1.0.6 in Redhat 7.2, gcc 2.96..... There are no errors with this, but there are in my applications...... When I make (compilation) my application there are no errors.......=20 but when I tryed to run it, I obtain next error: SIGSEV: violacion de segmento....... I update gcc by page Redhat.com ......=20 I do not what happend...... Does anybody can help me??? Please=20 Thanks a lot... Carlos Zebadua |
|
From: Scott J. <joh...@ve...> - 2002-11-07 18:41:32
|
Monika, The problem stems from the fact RedHat 8.0 changed the classic structure of certain X11 fonts, making them dynamically executable as opposed to static arrays. Bug 611266 highlighted the problem, and Bug 622854 showed how to modify existing idraw files to workaround the problem: http://sourceforge.net/tracker/index.php?func=detail&aid=622854&group_id=275&atid=100275 I've since changed the ivtools copy of idraw so that loading then saving an idraw EPS file will make this change to the file. This will be part of the next release of ivtools (either 1.1 or 1.0.7). In the meantime you can manually make the change described in Bug 622854, or apply the attached patch to your source copy of idraw and rebuild. Scott Johnston http://www.ivtools.org At 3:43 PM +0100 11/7/02, Monika Lundell wrote: >I'm a longtime idraw/Linux user and have recently been forced to move to a >RedHat 8.0 machine where I was soon confronted with the same problem that >Jon Heidemann wrote about in August: ghostview crashes as soon as there is >a character in the postscript file generated by idraw - and so do all other >ps-viewers I have tried and also ps2pdf. Other types of drawings seem OK, >it crashes only when there is a character. Changing to a simpler font >doesn't work. > >It seems the consensus in August was that it was a Ghostscript error but I >can't find anything about it on the Ghostscript site. > >I've tried to go back to Ghostscript 5.50 (RH8 comes with GS 7.05) but it >refuses to install since there are too many dependencies on later versions >of Ghostscript. > >Has anyone found a workaround? I would hate to lose all my idraw files. > > > Monika Lundell > mon...@ep... > > > >PS. Here is a typical error message from ghostview: > >Error: /rangecheck in --get-- >Operand stack: > --nostringval-- --nostringval-- --nostringval-- descender >0 --nostringval-- 1 >Execution stack: > %interp_exit .runexec2 --nostringval-- --nostringval-- >--nostringval-- 2 %stopped_push --nostringval-- >--nostringval-- --nostringval-- false 1 %stopped_push 1 >3 %oparray_pop 1 3 %oparray_pop .runexec2 >--nostringval-- --nostringval-- --nostringval-- 2 >%stopped_push --nostringval-- --nostringval-- --nostringval-- >--nostringval-- >Dictionary stack: > --dict:1050/1123(ro)(G)-- --dict:0/20(G)-- --dict:95/200(L)-- >--dict:36/51(L)-- --dict:1/17(L)-- --dict:5/17(L)-- >--dict:1/3(L)-- --dict:13/14(ro)(L)-- >Current allocation mode is local >GNU Ghostscript 7.05: Unrecoverable error, exit code 1 > > >------------------------------------------------------- >This sf.net email is sponsored by: See the NEW Palm >Tungsten T handheld. Power & Color in a compact size! >http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >_______________________________________________ >Ivtools-user mailing list >Ivt...@li... >https://lists.sourceforge.net/lists/listinfo/ivtools-user |
|
From: Monika L. <mon...@ep...> - 2002-11-07 13:43:17
|
I'm a longtime idraw/Linux user and have recently been forced to move to a RedHat 8.0 machine where I was soon confronted with the same problem that Jon Heidemann wrote about in August: ghostview crashes as soon as there is a character in the postscript file generated by idraw - and so do all other ps-viewers I have tried and also ps2pdf. Other types of drawings seem OK, it crashes only when there is a character. Changing to a simpler font doesn't work. It seems the consensus in August was that it was a Ghostscript error but I can't find anything about it on the Ghostscript site. I've tried to go back to Ghostscript 5.50 (RH8 comes with GS 7.05) but it refuses to install since there are too many dependencies on later versions of Ghostscript. Has anyone found a workaround? I would hate to lose all my idraw files. Monika Lundell mon...@ep... PS. Here is a typical error message from ghostview: Error: /rangecheck in --get-- Operand stack: --nostringval-- --nostringval-- --nostringval-- descender 0 --nostringval-- 1 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1050/1123(ro)(G)-- --dict:0/20(G)-- --dict:95/200(L)-- --dict:36/51(L)-- --dict:1/17(L)-- --dict:5/17(L)-- --dict:1/3(L)-- --dict:13/14(ro)(L)-- Current allocation mode is local GNU Ghostscript 7.05: Unrecoverable error, exit code 1 |
|
From: Scott J. <joh...@ve...> - 2002-10-31 19:13:02
|
At 10:46 AM -0600 10/31/02, Jon M. Powers wrote: >Please forgive me if this issue has been dealt with before, but I could >find no mention of this issue (at least as I see it) in the archives or >on google. > >When using idraw to prepare flowcharts and other block diagrams, I >typically use the gravity feature to make the various visual objects >"snap" to the grid. > >I have noticed that this works fine when I am initially creating the >object. But, when I use the stretch command to resize the object, the >object no longer fully snaps to the grid. For example, when resizing a >rectangle with the stretch command, at least one of the corners of the >rectangle usually no longer resides on a grid point after the operation. >Also, there appears to be no easy way to get that corner back onto the >grid > >I have seen this behavior with several versions of idraw and on several >platforms. > >I would like all objects to snap to the grid during all operations. Is >this possible? > >Thanks. > >Jon M. Powers > There seems to be a bug in gravity's interaction with the stretch command. It snaps it to the grid plus or minus an error amount. Why don't you file this is as a bug at http://sourceforge.net/projects/ivtools ? I'm sure it can get fixed sometime in the not too distant future. Scott Johnston |
|
From: Jon M. P. <po...@fo...> - 2002-10-31 16:51:06
|
Please forgive me if this issue has been dealt with before, but I could find no mention of this issue (at least as I see it) in the archives or on google. When using idraw to prepare flowcharts and other block diagrams, I typically use the gravity feature to make the various visual objects "snap" to the grid. I have noticed that this works fine when I am initially creating the object. But, when I use the stretch command to resize the object, the object no longer fully snaps to the grid. For example, when resizing a rectangle with the stretch command, at least one of the corners of the rectangle usually no longer resides on a grid point after the operation. Also, there appears to be no easy way to get that corner back onto the grid I have seen this behavior with several versions of idraw and on several platforms. I would like all objects to snap to the grid during all operations. Is this possible? Thanks. Jon M. Powers |
|
From: John H. <jo...@is...> - 2002-08-23 13:46:00
|
On Thu, 22 Aug 2002 14:11:11 PDT, "Scott Johnston" wrote: >> >> >>>>Specificially, if I create a new file with idraw 1.0.6 and put the >>>>text string "foo" in it, the gv the file using ghostscript-6.52-9.4 on >>>>Redhat 7.3, it gives the following error message: >>>> >>>>Error: /rangecheckGNU Ghostscript 6.52: Unrecoverable error, exit code 1 >>>> >>>> >To me this implies a bug in Ghostscript (or underlying library), not an >error in PostScript. > >>>>Current file position is 10438 >>>> >>>> >>>>Position 10438 is the first character of the "End" just after >>>>the "] Text" line in the file. >>>> > >It seems position 10438 is on the line before the "Begin %I Text"/ Sorry, the error I sent you was from a different file. The error in the foo.idraw I sent you is at file position 10606, the "End" just after the Text. > >>>> >>>>This problem didn't happen on Redhat Linux 7.2, but it persists even >>>>if I downgrade ghostview in RH 7.3 to the 7.2 version. >>>> >You would also need to downgrade ghostscript to the 7.2 version to see >if the problem >is specific to ghostscript-6.52. Did you do that? Yes, that should have read "if I downgrade ghost*script*" to the 7.2 version. What's odd is that this suggests the problem is in some system library, not ghostscript itself. >p.s. After writing all this I vaguely recall some conflict between >recent ghostscript and the idraw EPS format, but I can't locate any >documentation on this. Pinging the ghostscript maintainers (Raph >Levien) might stir up what that was (or was it just a hallucinated memory). Ok, I'll try to send the bug to the ghostscript folks as well. -John |
|
From: Scott J. <sc...@ac...> - 2002-08-22 21:15:38
|
> > >>>Specificially, if I create a new file with idraw 1.0.6 and put the >>>text string "foo" in it, the gv the file using ghostscript-6.52-9.4 on >>>Redhat 7.3, it gives the following error message: >>> >>>Error: /rangecheckGNU Ghostscript 6.52: Unrecoverable error, exit code 1 >>> >>> To me this implies a bug in Ghostscript (or underlying library), not an error in PostScript. >>>Current file position is 10438 >>> >>> >>>Position 10438 is the first character of the "End" just after >>>the "] Text" line in the file. >>> It seems position 10438 is on the line before the "Begin %I Text"/ >>> >>>This problem didn't happen on Redhat Linux 7.2, but it persists even >>>if I downgrade ghostview in RH 7.3 to the 7.2 version. >>> You would also need to downgrade ghostscript to the 7.2 version to see if the problem is specific to ghostscript-6.52. Did you do that? >>> >>> >>>1. Has anyone else observed this bug? >>> Not that I know of. >>> >>>2. Is this a ghostscript or idraw problem? >>>(Is idraw wrong and ghostscript is now more conservative in this release, or >>>did ghostscript regress.) >>> The test file you forwarded looks identical to what I generate on RH 6.2. I would say the problem stems from some change to ghostcript (or underlying libraries). Whether it is a bug or a tightening up on the accepted PostScript language remains to be seen. >>> >>>I hpoe it's fixable because I have lots of old idraw files that I like >>>to ghostview! >>> First figure out if you downgraded ghostscript at the same time you downgraded ghostview (from the RH 7.3 version to the RH 7.2 version). If so, I think you have a RH 7.3 specific problem with ghostscript and you could report that to the maintainers. If not, try that downgrade, and if there is still a problem you still have a RH 7.3 specific problem. Otherwise, you might have isolated a problem interpreting idraw EPS with the ghostscript 6.52. Which would be worth reporting to the ghostscript maintainers as well. Scott Johnston p.s. After writing all this I vaguely recall some conflict between recent ghostscript and the idraw EPS format, but I can't locate any documentation on this. Pinging the ghostscript maintainers (Raph Levien) might stir up what that was (or was it just a hallucinated memory). |
|
From: John H. <jo...@is...> - 2002-08-22 20:33:18
|
On Thu, 22 Aug 2002 11:14:55 PDT, "Scott Johnston" wrote: >John Heidemann wrote: > >>Has anyone else noticed that text in idraw gives errors in recent >>versions of ghostscript? >> >>Specificially, if I create a new file with idraw 1.0.6 and put the >>text string "foo" in it, the gv the file using ghostscript-6.52-9.4 on >>Redhat 7.3, it gives the following error message: >> >>Error: /rangecheckGNU Ghostscript 6.52: Unrecoverable error, exit code 1 >> in --get-- >>Operand stack: >> --nostringval-- --nostringval-- --nostringval-- descender 0 --nostringval-- 1 >>Execution stack: >> %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- >>Dictionary stack: >> --dict:1038/1476(ro)(G)-- --dict:0/20(G)-- --dict:90/200(L)-- --dict:36/51(L)-- --dict:1/17(L)-- --dict:5/17(L)-- --dict:1/3(L)-- --dict:14/17(ro)(L)-- >>Current allocation mode is local >>Current file position is 10438 >> >> >>Position 10438 is the first character of the "End" just after >>the "] Text" line in the file. >> >>This problem didn't happen on Redhat Linux 7.2, but it persists even >>if I downgrade ghostview in RH 7.3 to the 7.2 version. >> >> >>1. Has anyone else observed this bug? >> >>2. Is this a ghostscript or idraw problem? >>(Is idraw wrong and ghostscript is now more conservative in this release, or >>did ghostscript regress.) >> >>I hpoe it's fixable because I have lots of old idraw files that I like >>to ghostview! >> >> -John >> >> >> > >Sorry, away on vacation. > >Can you forward the idraw test file that gives you a problem (with the >single string of "foo")? > >I tried it with my copy of idraw from ivtools-1.0.6 and don't see the >same problem but I'm >using RH 6.2 and gs 5.50. > >This could be a ghostscript problem, or something relative to the >version of libstdc++ you have >linked into idraw. The attached file will reproduce the error. It has two elements: the string "bar" and a box. The box will display in gv, but the string crashes it. Deleting the sring makes the problem go away. However, you won't see this problem under RH 6.2. It only starts breaking in RH 7.3 (it works fine in RH versions through 7.2). I agree it's likely that it's really ghostscript that's changed. But it's not clear if idraw was always generating bad postscript and only now does ghostscript complain, or if ghostscript is complaining unfairly. -John |
|
From: Scott J. <sc...@ac...> - 2002-08-22 18:19:22
|
John Heidemann wrote: >Has anyone else noticed that text in idraw gives errors in recent >versions of ghostscript? > >Specificially, if I create a new file with idraw 1.0.6 and put the >text string "foo" in it, the gv the file using ghostscript-6.52-9.4 on >Redhat 7.3, it gives the following error message: > >Error: /rangecheckGNU Ghostscript 6.52: Unrecoverable error, exit code 1 > in --get-- >Operand stack: > --nostringval-- --nostringval-- --nostringval-- descender 0 --nostringval-- 1 >Execution stack: > %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- >Dictionary stack: > --dict:1038/1476(ro)(G)-- --dict:0/20(G)-- --dict:90/200(L)-- --dict:36/51(L)-- --dict:1/17(L)-- --dict:5/17(L)-- --dict:1/3(L)-- --dict:14/17(ro)(L)-- >Current allocation mode is local >Current file position is 10438 > > >Position 10438 is the first character of the "End" just after >the "] Text" line in the file. > >This problem didn't happen on Redhat Linux 7.2, but it persists even >if I downgrade ghostview in RH 7.3 to the 7.2 version. > > >1. Has anyone else observed this bug? > >2. Is this a ghostscript or idraw problem? >(Is idraw wrong and ghostscript is now more conservative in this release, or >did ghostscript regress.) > >I hpoe it's fixable because I have lots of old idraw files that I like >to ghostview! > > -John > > > Sorry, away on vacation. Can you forward the idraw test file that gives you a problem (with the single string of "foo")? I tried it with my copy of idraw from ivtools-1.0.6 and don't see the same problem but I'm using RH 6.2 and gs 5.50. This could be a ghostscript problem, or something relative to the version of libstdc++ you have linked into idraw. Scott Johnston > > |
|
From: John H. <jo...@is...> - 2002-08-09 16:41:51
|
Has anyone else noticed that text in idraw gives errors in recent versions of ghostscript? Specificially, if I create a new file with idraw 1.0.6 and put the text string "foo" in it, the gv the file using ghostscript-6.52-9.4 on Redhat 7.3, it gives the following error message: Error: /rangecheckGNU Ghostscript 6.52: Unrecoverable error, exit code 1 in --get-- Operand stack: --nostringval-- --nostringval-- --nostringval-- descender 0 --nostringval-- 1 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1038/1476(ro)(G)-- --dict:0/20(G)-- --dict:90/200(L)-- --dict:36/51(L)-- --dict:1/17(L)-- --dict:5/17(L)-- --dict:1/3(L)-- --dict:14/17(ro)(L)-- Current allocation mode is local Current file position is 10438 Position 10438 is the first character of the "End" just after the "] Text" line in the file. This problem didn't happen on Redhat Linux 7.2, but it persists even if I downgrade ghostview in RH 7.3 to the 7.2 version. 1. Has anyone else observed this bug? 2. Is this a ghostscript or idraw problem? (Is idraw wrong and ghostscript is now more conservative in this release, or did ghostscript regress.) I hpoe it's fixable because I have lots of old idraw files that I like to ghostview! -John |
36821 messages has been excluded from this view by a project administrator.
