White smoke ...
I succeeded in creating the Monte Carlo executable that links the CERN
library and the Tcl/Tk .a and .h files.
I just got rid of a macro that is proprietary for Sun Unix but it's
deleterius on Linux/Suse. The culprit is " -Df2cFortran".
This option was in the list of the CFLAGS and CXXFLAGS.
I realized it was junk when I launched "make -p".
This is a left-over from the installation procedure for Sun.
It's just amazing that "make" did not complain about it !
Thank you all for assisting me through this nightmare.
Maura
As you all have figured out I'm very new to Tcl/Tlk.
I was assigned the hard task to fix a couple of bugs in a Tcl/Tk GUI
implemented by someone else.
The existent GUI allows for left-button clicking on a color-coded
particles flux representation.
The numeric value of the flux is correctly displayed on a Point info
widget.
But for values greater than 10^9 (1e9) an error message pops up on the
screen which reads:
"Error in Tcl Script
Error: integer value too large to represent.
OK Skip Messages Stack Trace"
If I click on the Stack Trace button I get the following info that I
cannot quite understand:
integer value too large to represent
while executing
"expr $num-int($num)"
(procedure "format_vis" line 29)
invoked from within
"format_vis $hst_id """
(procedure "show_info_frame" line 106)
invoked from within
"show_info_frame 304 335"
(command bound to event)
In fact the package I'm testing includes a module named "mf.tcl" which
is a sequential collection of procs.
There is indeed the following boud proc:
bind $base.canvas_field <Button-1> {show_info_frame %x %y}
proc show_info_frame { h v } {
**** Question: ****
Is the 106 indicated in the Stack Trace an offset inside the proc
show_info_frame ?
The proc show_info_frame is at line 1558 of the "mf.tcl" file.
If I add ( 1558 + 106) = 1664 which is a line inside the
proc show_info_frame
but such a proc is NOT recursive. I mean it doesn't call itself.
Infact at line 1664 there is the following statement:
if { $plot(info_frame) == "" } {
There is indeed an "info_frame" but it's not a call to
proc show_info_frame.
I would appreciate if someone could help me interpret the information
provided in the Stack Trace with the hope that helps me find and fix the
bug.
Thank you in advance for your help,
Maura
I tried to get some info for the Tcl/Tk library file that is not linked
because it is regarded by the linker as "incompatible". .
mauede@linux:/home/mokhov/restricted/mars15/linux/lib> file -k libm15gui_linux.a
libm15gui_linux.a: current ar archive\012- archive file\012- Assembler source
Then I enquired about "ar". I remember Dr.Mockov typing "ar" during our
Monte Carlo code installation attempt. In fact I had never seen such a
command before and asked him about it. He said it archives files.
I just typed in "man ar" and read the following:
mauede@linux:~/cernlib.32-2005-ifh.de/2005/lib> man ar
NAME
ar - create, modify, and extract from archives
......................................................................
......................................................................
ar ignores an initial option spelt -X32_64, for compatibility with
AIX. The behaviour produced by this option is the default for GNU ar.
ardoes not support any of the other -X options; in particular, it does
not support -X32 which is the default for AIX ar.
What is the meaning and consequence of not supporting the option "-X32" ?
I do not know what this option does (never seen before) and am caught by
phobia at reading he magic number "32" .... I wonder if there is any
relation with this unsupported option and the linker regarding the file
"libm15gui_linux.a" as incompatible with the rest of the objects being
generated by compiling with the option -m32 ....
See the following errors returned by the linker ....
*************************************************************************
* Errors from launching the make that includes all libraries
*
*************************************************************************
mauede@linux:/home/mokhov/restricted/mars15> make
g77 -m32 -static -L/home/mauede/cernlib.32- 2005-ifh.de/2005/lib
-L/home/mokhov/restricted/mars15/linux/lib
-L/home/mokhov/restricted/mcnp4c/linux/lib
-L/home/mokhov/restricted/mars15/linux/lib
-L/home/mokhov/restricted/mars15/linux/lib -o rmars-bnab-fems-linux
marsmain.o m1505.o -lm15gui_linux -lm15linux -lm15fems_linux
-lm15trneu_linux -lm15treem_linux -lm15eve_linux -lm15cem03_linux
-lm15ext_linux -lm15blb_linux -lm15mpino_linux -lm15linux -lpacklib
-ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lnsl -lpthread
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible
/home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching
for -lm15gui_linux
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible
/home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching
for -lm15gui_linux
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible
/home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching
for -lm15gui_linux
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld:
cannot find -lm15gui_linux
collect2: ld returned 1 exit status
make: *** [rmars-bnab-fems-linux] Error 1
--
Maura E.M
All,
I've got a suspected stack corruption, and as it involves an external
library, I'm trying to determine who's to blame - my code or the
library code. Without exception, the resulting segfault always happens
in the external library (libclamav). Equally without exception, if I
omit the single call to the library (cl_scanfile()), I see no problems.
I'm not particularly familiar with the libclamav code, nor so I have a
desire to become so, so I was hoping to come up with something that
says the problem is in libclamav - without diagnosing the problem all
the way.
It's little difficult to reproduce - I have had stresstests run for 24+
hours before it happened, but it has also happened within 30mins of
starting a test.
/Per Jessen, Zürich
White smoke ...
I succeeded in creating the Monte Carlo executable that uses the CERN
library and Tcl/Tk .a and .h files !
I just got rid of a macro that is proprietary for Sun Unix but it's
deleterius on Linux/Suse.
The culprit option was " -Df2cFortran"
Thank you all for assisting me through this nightmare.
Maura
My laptop has a AMD Athlon 64 Processor 3700+, Architecture is x86_64.
My problem is that I have to compile a code that will then be linked to
pre-compile binaries produced on 32-bit machines.
In short, everything must be compiled to generate 32-bit code for the sake
of compatibility.
There should be an option in the gcc compiler that forces it to generate
32-bit code..
But assuming I've got an executable for 32-bit machines, then can I run
such an exectable on MY OWN laptop which is 64-bit ?
If the answer is "yes" (I hope so) then I'd be grateful to know how I can
do that .
Thank you in advance for your help.
Maura
I've seen a number of documents and code that prefers to use the newline
character ("\n" or '\n') rather than std::endl
In the general case, the issue is that endl forces a buffer flush where '\n'
does not, and therefore using the newline is more efficient. However, using
endl is more portable. Either way works fine on Linux. Comments...
--
Jerry Feldman <gaf(a)blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Is it possible that on a 32-bit machine the maximum value for a Real
number in Tcl language is 10^10 ?
Instinctively I'd saythe number of bits assigned to the representation of
a Real number is independent on the machine h/w architecture ... but I'm
not familiar with Tcl and may be mistaken ...
Thank you,
MEM
Maura Edeweiss Monville <memonvil(a)artsci.wustl.edu> writes:
> Is it possible that on a 32-bit machine the maximum value for a Real
> number in Tcl language is 10^10 ?
See: http://wiki.tcl.tk/11969
"Computers and real numbers"
The maximum range for Tcl is 1.0e-200 to 1.0e+200, but the precision
is only 12 to 13 decimals. There are arbitrary precision Tcl library
packages available which are mentioned in that article.
> Instinctively I'd saythe number of bits assigned to the representation of
> a Real number is independent on the machine h/w architecture ... but I'm
> not familiar with Tcl and may be mistaken ...
I apologize for posting a question to the wrong mailing list. I'm relying
on the generosity and understanding of the subscribers.
I've no experience of programming in Tcl language.
Today I was shown the wierd behaviour of a Tcl/Tk GUI and asked to help
fix the following problem.
Basically a parameter representing a scale factor is entered through the
keyboard. If the entered value is less than 10^10 then the program
behaviour is correct. If the entered value exceeds 10^10 then no error is
eturned but the interface behaviour is not correct as the scaling factor
is not correctly applied.
Questions:
1) is there a maximum value that can be represented ?
2) if the answer to 1) is "yes" then is 10^10 the maximum value that can
be stored in a variable ?
3) if the answers to both 1) and 2) is "yes" then is it possible to deal
with values greater than 10^10 ? How ?
Thank you very much for your help.
Maura
