Problem with building Tcl both with and without symbols
Erik Leunissen
I'm used to install two versions of each Tcl release: a regular version,
built with "configure --disable symbols" and a version for debugging,
built with "configure --enable-symbols".
The latter build configuration used to[*] produce debug libraries that
have an extra "g" character in their names, e.g. libtcl8.4g.so as
compared to their regular counterparts which lack that extra "g":
libtcl8.4.so.
The only thing I needed to take care of is the name of the debug
executable, which is just "tclsh", and I simply rename that manually to
"tclshg" to prevent overwriting or confusion with a regular executable.
[*] I'm talking about the tcl 8.4.19 source release.
Now, with the tcl 8.5.6 source release, the "--enable-symbols"
configuration produces debug libraries which don't have the extra "g" in
their names: "libtcl8.5.so", and (of course) the debug executable
depends on it. So now both the regular and the debug executable depend
on libraries which carry the same name. Go figure ...
This means that I can't have installed (and use) both a debug and a
regular version of tcl without a renaming scheme that I need to apply
twice: once at installation time to prevent that debug libraries
overwrite regular libraries, and later at execution time to make the
debug executable use the debug library. That's so tedious ...
Has the configuration change that I observe between 8.4.19 and 8.5.6
been made on purpose?
Thanks for your attention,
Erik Leunissen
--
leunissen@ nl | Merge the left part of these two lines into one,
e. hccnet. | respecting a character's position in a line.
Don Porter
> Now, with the tcl 8.5.6 source release, the "--enable-symbols"
> configuration produces debug libraries which don't have the extra "g" in
> their names: "libtcl8.5.so", and (of course) the debug executable
> depends on it.
> Has the configuration change that I observe between 8.4.19 and 8.5.6
> been made on purpose?
I think you're asking about Tcl Patch 1081595.
2005-01-10 Joe English <jeng...@users.sourceforge.net>
* unix/Makefile.in, unix/configure.in, unix/tcl.m4,
* unix/tclConfig.sh.in, unix/dltest/Makefile.in:
Remove ${DBGX}, ${TCL_DBGX} from Tcl build system [Patch 1081595].
* unix/configure: regenerated
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Erik Leunissen
>
> I think you're asking about Tcl Patch 1081595.
>
> 2005-01-10 Joe English <jeng...@users.sourceforge.net>
>
> * unix/Makefile.in, unix/configure.in, unix/tcl.m4,
> * unix/tclConfig.sh.in, unix/dltest/Makefile.in:
> Remove ${DBGX}, ${TCL_DBGX} from Tcl build system [Patch 1081595].
> * unix/configure: regenerated
>
Yes, it appears that I was. Thanks for the pointer.
I can't judge how awkward ${TCL_DBGX} must have been to maintain, but
from a private point of view I'm sorry to understand that a dual install
(debug/regular) isn't supported anymore.
Erik.
Sp...@controlq.com
...
> I can't judge how awkward ${TCL_DBGX} must have been to maintain, but
> from a private point of view I'm sorry to understand that a dual install
> (debug/regular) isn't supported anymore.
>
>
> Erik.
>
Why not just build a single (debug) version, then copy it, and strip the
symbols from the production shell?? Not sure what platform you're using,
but even if windows, the mingw build supports a version of strip ...
Rob.
Erik Leunissen
> Erik,
>
> Why not just build a single (debug) version, then copy it, and strip the
> symbols from the production shell?? Not sure what platform you're
> using, but even if windows, the mingw build supports a version of strip ...
>
Oh, the issue isn't that I can't produce a stripped executable. The
issue is that I want the speed of an optimized executable for regular
cases, but occasionally need the debug symbols for debugging purposes.
Although, now I come to think of it, by default the Tcl executables
produced by "--enable-symbols" and "--disable-symbols" do not differ
with respect to the degree of optimization, so I shouldn't notice any
performance difference right?
Hmm, it seems that my initial concern isn't valid.
Thanks for making me think again.
Erik.
> Rob.
George Peter Staplin
> Sp...@ControlQ.com wrote:
>> Erik,
>>
>> Why not just build a single (debug) version, then copy it, and strip the
>> symbols from the production shell?? Not sure what platform you're
>> using, but even if windows, the mingw build supports a version of strip
>> ...
>>
>
> Oh, the issue isn't that I can't produce a stripped executable. The
> issue is that I want the speed of an optimized executable for regular
> cases, but occasionally need the debug symbols for debugging purposes.
>
> Although, now I come to think of it, by default the Tcl executables
> produced by "--enable-symbols" and "--disable-symbols" do not differ
> with respect to the degree of optimization, so I shouldn't notice any
> performance difference right?
Potentially there is some cost, but a more important issue may be that
debugging is often not so useful with optimization and symbols. A lot of
values are optimized away.
If you use some flags like --enable-symbols=mem then you also need to build
every extension with the same flags Tcl uses, or things break. The macros
are used in a way that really isn't optimal. I understand it's probably
for performance reasons that we don't use the Tcl_Db-style macros by
default always, but it makes debugging Tcl_Obj and memory-related problems
much more difficult when I have to rebuild every extension to track where
the Tcl_Obj was allocated and released.
-George
Larry W. Virden
>
> I can't judge how awkward ${TCL_DBGX} must have been to maintain, but
> from a private point of view I'm sorry to understand that a dual install
> (debug/regular) isn't supported anymore.
>
Once that useful functionality was removed, I just began building
everything with the symbols. The libraries and executables are larger,
but at least if a core occurs there is useful information available.
Erik Leunissen
>
> Potentially there is some cost, but a more important issue may be that
> debugging is often not so useful with optimization and symbols. A lot of
> values are optimized away.
>
The Makefile, generated by default from "configure --enable-symbols"
uses both -g and -O2 as compiler switches.
Did you mean to say that this isn't a very useful combination?
Erik.
> If you use some flags like --enable-symbols=mem then you also need to build
> every extension with the same flags Tcl uses, or things break. The macros
> are used in a way that really isn't optimal. I understand it's probably
> for performance reasons that we don't use the Tcl_Db-style macros by
> default always, but it makes debugging Tcl_Obj and memory-related problems
> much more difficult when I have to rebuild every extension to track where
> the Tcl_Obj was allocated and released.
>
> -George
George Peter Staplin
> George Peter Staplin wrote:
>>
>> Potentially there is some cost, but a more important issue may be that
>> debugging is often not so useful with optimization and symbols. A lot
>> of values are optimized away.
>>
>
> The Makefile, generated by default from "configure --enable-symbols"
> uses both -g and -O2 as compiler switches.
>
> Did you mean to say that this isn't a very useful combination?
Yes, that's what I was implying by "debugging is often not so useful with
optimization and symbols."
The context of the code gets lost, and gdb and other debuggers will often
state "<value optimized away>" with optimized builds.
Erik Leunissen
>> The Makefile, generated by default from "configure --enable-symbols"
>> uses both -g and -O2 as compiler switches.
>>
>> Did you mean to say that this isn't a very useful combination?
>
> Yes, that's what I was implying by "debugging is often not so useful with
> optimization and symbols."
>
> The context of the code gets lost, and gdb and other debuggers will often
> state "<value optimized away>" with optimized builds.
>
Yes, I understand the reason in general.
Would you support a submission to the Tcl tracker proposing to drop
"-O1", "-O2" or any other optimization switch, when generating a debug
build?
Erik.
>> Erik.
>>
>>> If you use some flags like --enable-symbols=mem then you also need to
>>> build
>>> every extension with the same flags Tcl uses, or things break. The
>>> macros
>>> are used in a way that really isn't optimal. I understand it's probably
>>> for performance reasons that we don't use the Tcl_Db-style macros by
>>> default always, but it makes debugging Tcl_Obj and memory-related
>>> problems much more difficult when I have to rebuild every extension to
>>> track where the Tcl_Obj was allocated and released.
>>>
>>> -George
>>
>
George Peter Staplin
> George Peter Staplin wrote:
>>> The Makefile, generated by default from "configure --enable-symbols"
>>> uses both -g and -O2 as compiler switches.
>>>
>>> Did you mean to say that this isn't a very useful combination?
>>
>> Yes, that's what I was implying by "debugging is often not so useful with
>> optimization and symbols."
>>
>> The context of the code gets lost, and gdb and other debuggers will often
>> state "<value optimized away>" with optimized builds.
>>
>
> Yes, I understand the reason in general.
>
> Would you support a submission to the Tcl tracker proposing to drop
> "-O1", "-O2" or any other optimization switch, when generating a debug
> build?
>
> Erik.
While I agree that would be for the best, this kind of direction is usually
met by force by the developer that added -O2 for some unknown reason. I
don't like politics in general, but feel free to try to get that done.
I argued for 30 minutes or longer, and found several references just to
justify making Tcl_DecrRefCount use do { } while(0) in tcl.h, so that it
would be a single statement and not cause compilation errors in some cases.
I have seen Stuart Cassoff go through similar adventures trying to get some
patches merged.
After a while, it's kind of like: why bother? I have better things to do
with my time.
-George