From: James M. D. <mdu...@ya...> - 2002-12-31 09:07:11
|
Thank you very much for the detailed explaination. Yes, I should have included the file with me, or even a -x copy of it. On that note, do you have a way to -save-temps like gcc does, like +x so that you can capture the fully post-preprocessed files? I am cvs updating and will tell you how I fare. it is funny, but i had a feeling that those long indentifiers were created out of some hashing scheme, I encountered similar longs ids using hashes in shell before, just concatinating the symbols into one... Happy new year! mike --- "R. Bernstein" <ro...@pa...> wrote: > A guess is the problem is that you have a plus (or some other > character that isn't usually part of a BASH identifier) in the > filename. > > +2D0M2D0D6Slibtool > ^here > > Some background. For the debugger, it is very useful to have a hash > table data structure. Hash tables are not part of bash (yet). The way > these are implemented is to convert what in Perl would be $file{key} > into a single identifier "file_key" making use of BASH's hashed > symbol > table. > > But in order to do this "key" can't have any non-identifer symbols, > like "+", "/", "." and so on. So these must either be stripped or > replaced. We in fact, replace them to make it easier to recontruct > the > original name. Right now I don't list all the weird symbols that > might > appear in a filename. In particular, I don't have "+" listed. > > Doing a reverse translation of +2D0M2D0D6Slibtool the original > filename with a path probably contained something like > "+2.0-2-0.6/libtool", possibly with other stuff in front. If this is > the case, then a simple fix is to make sure we tranlate the "+" in > _bashdb_file2var. That is, change this line 22 of bashdb-file.inc: > > local varname=`builtin echo $filename | tr '* .?/"[]-' 'ABDQSqLRM'` > > into this: > > local varname=`builtin echo $filename | tr '+* .?/"[]-' > 'PABDQSqLRM'` > > Actually, I've already made the change in CVS. > > If that works, let me know. If not, it would be helpful to understand > not just what the error message you encountered given below, but some > short example giving *input* that you typed to get that output. > Better, is a short test case that causes the debugger to fail. > > Thanks. > > > James Michael DuPont writes: > > > > --- "R. Bernstein" <ro...@pa...> wrote: > > > Hi there, Ho there, > > > > > > Okay. Thanks for the information and looking into bashdb. If you > have > > > questions, comments, or problems with bashdb let us know. > > > > > I am running this on libtool > > > > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local: > > +2D0M2D0D6Slibtool: value too great for base (error token is > > "2D0M2D0D6Slibtool") > > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local: > > +2D0M2D0D6Slibtool: value too great for base (error token is > > "2D0M2D0D6Slibtool") > > > > # the line is > > local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_" > > $filevar` > > # echo "debug: -- max_line: $max_line --" > > > > bash -x ../libtool --mode=link i586-mingw32msvc-gcc > > -DGLIB_STATIC_COMPILATION -mms-bitfields -Wall -D_REENTRANT > > -I/usr/local/win32/include -I/usr/local/win32/include/glib-2.0/ > > -mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe > > test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/ > -lgdi32 > > -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv > > > > It has something to do with the size of the identfiers, > > i will gdb it. > > > > mike > > > > ===== > > James Michael DuPont > > http://introspector.sourceforge.net/ > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |