Can (non-)debug versions of Perl coexist?
Elizabeth Mattijsen
perl executable with debugging symbols, and one without debugging
symbols, co-exist with the same prefix?
What I usually do when I get a new Perl version (RC or better), I
make the following versions:
- standard
- threaded
- standard with debugging symbols
- threaded with debugging symbols
with as the only difference the ./configure line (whether or not to
have "-Dusethreads" and "-Doptimize='-g'")
If this is not possible, is it at least officially possible to do
this for threaded and unthreaded executables?
I was living under the impression that this should always work. At
least in the given order of making the executables. I'm seeing weird
things now on Mac OS X with 5.8.3-RC1 and wonder if I'm looking at a
bug or whether reality has finally caught up with me... ;-)
Liz
H.Merijn Brand
> I was wondering whether it is _supposed_ to be possible to have a
> perl executable with debugging symbols, and one without debugging
> symbols, co-exist with the same prefix?
>
> What I usually do when I get a new Perl version (RC or better), I
> make the following versions:
>
> - standard
> - threaded
> - standard with debugging symbols
> - threaded with debugging symbols
>
> with as the only difference the ./configure line (whether or not to
> have "-Dusethreads" and "-Doptimize='-g'")
Only if you do use a different install tree
The perl executable itself can co-exist with (no-)debugging, but since the
folder names are not extended with -dbg or somsuch like -thread, the binary
versions of the modules might clash
One can force the extension. If not by option (don't know on top of my head
now), you can modify the tree folder names in config.sh after Configure
> If this is not possible, is it at least officially possible to do
> this for threaded and unthreaded executables?
Threaded and unthreaded should live happy together
> I was living under the impression that this should always work. At
> least in the given order of making the executables. I'm seeing weird
> things now on Mac OS X with 5.8.3-RC1 and wonder if I'm looking at a
> bug or whether reality has finally caught up with me... ;-)
>
>
> Liz
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Dave Mitchell
> On Thu 08 Jan 2004 22:05, Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
> > I was wondering whether it is _supposed_ to be possible to have a
> > perl executable with debugging symbols, and one without debugging
> > symbols, co-exist with the same prefix?
> >
> > What I usually do when I get a new Perl version (RC or better), I
> > make the following versions:
> >
> > - standard
> > - threaded
> > - standard with debugging symbols
> > - threaded with debugging symbols
> >
> > with as the only difference the ./configure line (whether or not to
> > have "-Dusethreads" and "-Doptimize='-g'")
>
> Only if you do use a different install tree
>
> The perl executable itself can co-exist with (no-)debugging, but since the
> folder names are not extended with -dbg or somsuch like -thread, the binary
> versions of the modules might clash
>
> One can force the extension. If not by option (don't know on top of my head
> now), you can modify the tree folder names in config.sh after Configure
>
> > If this is not possible, is it at least officially possible to do
> > this for threaded and unthreaded executables?
>
> Threaded and unthreaded should live happy together
Even then, lib/Config.pm is shared which may cause funny problems,
especially when building new modules.
--
O Unicef Clearasil!
Gibberish and Drivel!
- "Bored of the Rings"
Elizabeth Mattijsen
Eh... I think that is incorrect. Locate finds these 5.8.3 Config.pm files:
/usr/local/lib/perl5/5.8.3/i686-linux/Config.pm
/usr/local/lib/perl5/5.8.3/i686-linux/Encode/Config.pm
/usr/local/lib/perl5/5.8.3/i686-linux-thread-multi/Config.pm
/usr/local/lib/perl5/5.8.3/i686-linux-thread-multi/Encode/Config.pm
/usr/local/lib/perl5/5.8.3/CPAN/Config.pm
/usr/local/lib/perl5/5.8.3/CPAN/Config.pm~
/usr/local/lib/perl5/5.8.3/Net/Config.pm
so it seems to me that different Config.pm's are written for threaded
and unthreaded.
Liz
Elizabeth Mattijsen
Yep, there are two versions of Config.pm:
$ perl5.8.3-threaded -MConfig -e 'print values %INC,$/'
/usr/local/lib/perl5/5.8.3/i686-linux-thread-multi/Config.pm
$ perl5.8.3-unthreaded -MConfig -e 'print values %INC,$/'
/usr/local/lib/perl5/5.8.3/i686-linux/Config.pm
Liz
H.Merijn Brand
> At 22:11 +0000 1/8/04, Dave Mitchell wrote:
> >On Thu, Jan 08, 2004 at 10:47:29PM +0100, H.Merijn Brand wrote:
> > > Threaded and unthreaded should live happy together
> >Even then, lib/Config.pm is shared which may cause funny problems,
> >especially when building new modules.
>
> Eh... I think that is incorrect. Locate finds these 5.8.3 Config.pm files:
>
* /usr/local/lib/perl5/5.8.3/i686-linux/Config.pm
/usr/local/lib/perl5/5.8.3/i686-linux/Encode/Config.pm
* /usr/local/lib/perl5/5.8.3/i686-linux-thread-multi/Config.pm
/usr/local/lib/perl5/5.8.3/i686-linux-thread-multi/Encode/Config.pm
/usr/local/lib/perl5/5.8.3/CPAN/Config.pm
/usr/local/lib/perl5/5.8.3/CPAN/Config.pm~
/usr/local/lib/perl5/5.8.3/Net/Config.pm
Only the two '*' marked Config.pm's count here. But you probably guessed
There's nothing withholding you from creating
/usr/local/lib/perl5/5.8.3/i686-linux-dbg/Config.pm
/usr/local/lib/perl5/5.8.3/i686-linux-thread-multi-dbg/Config.pm
:)
and have
/usr/local/bin/perl => i686-linux
/usr/local/bin/perl-dbg => i686-linux-dbg
/usr/local/bin/perl-t => i686-linux-thread-multi
/usr/local/bin/perl-t-dbg => i686-linux-thread-multi-dbg
> so it seems to me that different Config.pm's are written for threaded
> and unthreaded.
Andrew Dougherty
> I was wondering whether it is _supposed_ to be possible to have a
> perl executable with debugging symbols, and one without debugging
> symbols, co-exist with the same prefix?
No, it's not supposed to be possible. In fact, that's the exact scenario
I used in the INSTALL file to warn about conflicts. Although that section
is mostly about shared libperl.so (which is where problems usually first
came up) it applies more generally as well.
One could change Configure to automatically add -debug to $archname if
debugging is selected, but no one's actually done that yet.
> If this is not possible, is it at least officially possible to do
> this for threaded and unthreaded executables?
Yes, almost -- they will have the same binary 'perl', but the
architecture-dependent libraries will be different.
--
Andy Dougherty doug...@lafayette.edu
Elizabeth Mattijsen
>On Thu, 8 Jan 2004, Elizabeth Mattijsen wrote:
> > I was wondering whether it is _supposed_ to be possible to have a
>> perl executable with debugging symbols, and one without debugging
> > symbols, co-exist with the same prefix?
>No, it's not supposed to be possible. In fact, that's the exact scenario
>I used in the INSTALL file to warn about conflicts. Although that section
>is mostly about shared libperl.so (which is where problems usually first
>came up) it applies more generally as well.
I missed the implications if you don't have a libperl.so (which seems
to be the default case on Linux as well on Mac OS X, at least since
5.8.1).
>One could change Configure to automatically add -debug to $archname if
>debugging is selected, but no one's actually done that yet.
Wouldn't that make a lot of sense? If someone can give me some
pointers on how to do this (Merijn?), I would try to get that
together. It would definitely be an itch of mine that would be
scratched by it.. ;-)
> > If this is not possible, is it at least officially possible to do
> > this for threaded and unthreaded executables?
>Yes, almost -- they will have the same binary 'perl', but the
>architecture-dependent libraries will be different.
That's no problem: a perlN.N.N is also generated. Now, if that would
have automatically have the right "-threaded|-unthreaded,]-debug"
postfixes, that would be even better! The 4 executables that I have
for Perl are (since 5.8.0):
perl5.8.X-unthreaded
perl5.8.X-threaded
perl5.8.X-unthreaded-debug
perl5.8.X-threaded-debug
Some people might think it's a bit verbose, but with automatic
command line extenders, I don't think it's such a big issue.
Liz
Nicholas Clark
> At 21:48 -0500 1/8/04, Andrew Dougherty wrote:
> >One could change Configure to automatically add -debug to $archname if
> >debugging is selected, but no one's actually done that yet.
>
> Wouldn't that make a lot of sense? If someone can give me some
> pointers on how to do this (Merijn?), I would try to get that
> together. It would definitely be an itch of mine that would be
> scratched by it.. ;-)
IIRC I've always just done it by hand by editing config.sh
I think if you run Configure interactively you can actually rejig the
architecture name in the answer to one of the questions.
There seem to be three options
0: as is - -g doesn't change archname
1: -g always changes archname
2: Configure asks whether -g should change the archname
(option 2 would mean that you could pass the flag on Configure's command line)
I'm not sure if having/not having the same archname is a good thing.
> That's no problem: a perlN.N.N is also generated. Now, if that would
> have automatically have the right "-threaded|-unthreaded,]-debug"
> postfixes, that would be even better! The 4 executables that I have
> for Perl are (since 5.8.0):
>
> perl5.8.X-unthreaded
> perl5.8.X-threaded
> perl5.8.X-unthreaded-debug
> perl5.8.X-threaded-debug
>
> Some people might think it's a bit verbose, but with automatic
> command line extenders, I don't think it's such a big issue.
Been there. Done that. :-)
$ ./installperl -h
Usage ./installperl: [switches]
-A Also install perl with the architecture's name in the perl binary's
name.
I think I added it, but it may have been Abigail. Pretty sure we both wanted
that feature at the same time.
Nicholas Clark
Tim Bunce
> On Thu, 8 Jan 2004, Elizabeth Mattijsen wrote:
>
> > I was wondering whether it is _supposed_ to be possible to have a
> > perl executable with debugging symbols, and one without debugging
> > symbols, co-exist with the same prefix?
>
> No, it's not supposed to be possible. In fact, that's the exact scenario
> I used in the INSTALL file to warn about conflicts. Although that section
> is mostly about shared libperl.so (which is where problems usually first
> came up) it applies more generally as well.
>
> One could change Configure to automatically add -debug to $archname if
> debugging is selected, but no one's actually done that yet.
I vagely recall it being discussed many many years ago, when the
archname concept was added, and the feeling being that debug should
change as little as possible because it might make archname-sensitive
code harder to debug.
But I doubt that would be a problem in practice. The change is
trivial and would certainly avoid a bunch of other headaches.
Tim.
Tim Bunce
>
> > > this for threaded and unthreaded executables?
> >Yes, almost -- they will have the same binary 'perl', but the
> >architecture-dependent libraries will be different.
>
> That's no problem: a perlN.N.N is also generated. Now, if that would
> have automatically have the right "-threaded|-unthreaded,]-debug"
> postfixes, that would be even better! The 4 executables that I have
> for Perl are (since 5.8.0):
>
> perl5.8.X-unthreaded
> perl5.8.X-threaded
> perl5.8.X-unthreaded-debug
> perl5.8.X-threaded-debug
>
> Some people might think it's a bit verbose, but with automatic
> command line extenders, I don't think it's such a big issue.
See the -A option to installperl.
Usage ./installperl: [switches]
-n Don't actually run any commands; just print them.
-s Run strip on installed binaries.
-v Only install perl as a binary with the version number in the name.
(Override whatever config.sh says)
+v Install perl as "perl" and as a binary with the version number in
the name. (Override whatever config.sh says)
-S Silent mode.
-f Force installation (don't check if same version is there)
-o Skip checking for other copies of perl in your PATH.
-V Verbose mode.
-A Also install perl with the architecture's name in the perl binary's
name.
-p Don't install the pod files. [This will break use diagnostics;]
-netware Install correctly on a Netware server.
Tim.
Elizabeth Mattijsen
>On Fri, Jan 09, 2004 at 09:53:56AM +0100, Elizabeth Mattijsen wrote:
> > At 21:48 -0500 1/8/04, Andrew Dougherty wrote:
> > >One could change Configure to automatically add -debug to $archname if
> > >debugging is selected, but no one's actually done that yet.
> > Wouldn't that make a lot of sense? If someone can give me some
>> pointers on how to do this (Merijn?), I would try to get that
>> together. It would definitely be an itch of mine that would be
> > scratched by it.. ;-)
>IIRC I've always just done it by hand by editing config.sh
>I think if you run Configure interactively you can actually rejig the
>architecture name in the answer to one of the questions.
>
>There seem to be three options
>
>0: as is - -g doesn't change archname
>1: -g always changes archname
>2: Configure asks whether -g should change the archname
If you consider it to be a bug that creating a debug version is able
top clobber a non-debug installation, then I think 1. could be
considered a bug fix.
>(option 2 would mean that you could pass the flag on Configure's command line)
>I'm not sure if having/not having the same archname is a good thing.
The only worry I have is when a distribution has architecture
specific and non-architecture specific parts. My understanding is
that _all_ modules would either be install in architecture specific
or non-architecture specific directories. If that is not true, then
there may be a problem.
> > perl5.8.X-unthreaded
>> perl5.8.X-threaded
>> perl5.8.X-unthreaded-debug
> > perl5.8.X-threaded-debug
> > Some people might think it's a bit verbose, but with automatic
> > command line extenders, I don't think it's such a big issue.
>Been there. Done that. :-)
>
>$ ./installperl -h
>Usage ./installperl: [switches]
>
> -A Also install perl with the architecture's name in the
>perl binary's
> name.
Hmm... I usually do "make install", which I assume calls
./installperl. Can you make the -A flag be passed to ./installperl
from Configure?
>I think I added it, but it may have been Abigail. Pretty sure we both wanted
>that feature at the same time.
And a good feature it is. You learn something every day... ;-)
Liz
H.Merijn Brand
> At 11:26 +0000 1/9/04, Nicholas Clark wrote:
> >On Fri, Jan 09, 2004 at 09:53:56AM +0100, Elizabeth Mattijsen wrote:
> > > At 21:48 -0500 1/8/04, Andrew Dougherty wrote:
> > > >One could change Configure to automatically add -debug to $archname if
> > > >debugging is selected, but no one's actually done that yet.
> > > Wouldn't that make a lot of sense? If someone can give me some
> >> pointers on how to do this (Merijn?), I would try to get that
> >> together. It would definitely be an itch of mine that would be
> > > scratched by it.. ;-)
> >IIRC I've always just done it by hand by editing config.sh
> >I think if you run Configure interactively you can actually rejig the
> >architecture name in the answer to one of the questions.
> >
> >There seem to be three options
> >
> >0: as is - -g doesn't change archname
> >1: -g always changes archname
> >2: Configure asks whether -g should change the archname
>
> If you consider it to be a bug that creating a debug version is able
I don't. How many people would install both?
It's far more likely that people will install threaded/non-threaded and
32bit/64bit versions alongside (think databases)
Only the people that compile perl themselves on a regular basis are likely
candidates ti install debug/non-debug alongside
> top clobber a non-debug installation, then I think 1. could be
> considered a bug fix.
IMHO it is not
> >(option 2 would mean that you could pass the flag on Configure's command line)
> >I'm not sure if having/not having the same archname is a good thing.
You don't want to distribute debugging versions of perl.
Your client does not want debugging versions of perl: it's slower
> The only worry I have is when a distribution has architecture
> specific and non-architecture specific parts. My understanding is
> that _all_ modules would either be install in architecture specific
> or non-architecture specific directories. If that is not true, then
> there may be a problem.
>
>
> > > perl5.8.X-unthreaded
> >> perl5.8.X-threaded
> >> perl5.8.X-unthreaded-debug
> > > perl5.8.X-threaded-debug
> > > Some people might think it's a bit verbose, but with automatic
> > > command line extenders, I don't think it's such a big issue.
> >Been there. Done that. :-)
> >
> >$ ./installperl -h
> >Usage ./installperl: [switches]
> >
> > -A Also install perl with the architecture's name in the
> >perl binary's
> > name.
>
> Hmm... I usually do "make install", which I assume calls
> ./installperl. Can you make the -A flag be passed to ./installperl
> from Configure?
No :)
> >I think I added it, but it may have been Abigail. Pretty sure we both wanted
> >that feature at the same time.
>
> And a good feature it is. You learn something every day... ;-)
--
Nick Ing-Simmons
>
>IIRC I've always just done it by hand by editing config.sh
>I think if you run Configure interactively you can actually rejig the
>architecture name in the answer to one of the questions.
I always build with -g and then strip if I want one without.
-g isn't supposed to change the generated code (RMS gets livid
if it does ...)
The real issue is whether perl is build with -DDEBUGGING which would
be different code.
I have always thought that -g turning on -DDEBUGGING was okay as
a default but a bit clumsy.
>
>There seem to be three options
>
>0: as is - -g doesn't change archname
>1: -g always changes archname
>2: Configure asks whether -g should change the archname
s/-g/-DDEBUGGING/ ?
Nick Ing-Simmons
>
>You don't want to distribute debugging versions of perl.
_I_ do.
>Your client does not want debugging versions of perl: it's slower
So what - if that allows me to fix clients bugs via remote login
or "run this with -Do and send me results".
Beware confusing -DDEBUGGING with -g
If if I give them a -UDEBUGGING perl I still want enough
symbols to get backtraces from core files when XS code goes boom.
H.Merijn Brand
> H.Merijn Brand <h.m....@hccnet.nl> writes:
> >
> >You don't want to distribute debugging versions of perl.
>
> _I_ do.
>
> >Your client does not want debugging versions of perl: it's slower
>
> So what - if that allows me to fix clients bugs via remote login
> or "run this with -Do and send me results".
>
> Beware confusing -DDEBUGGING with -g
I was not. _You_ have a good reason to do so, but in this case you will
probably have no version _without_ -DDEBUGGING, so there is no conflict
> If if I give them a -UDEBUGGING perl I still want enough
> symbols to get backtraces from core files when XS code goes boom.
-DDEBUGGING sets -g automatically in Configure
-DDEBUGGING slows down perl, -g does not (or at least not so much to notice)
H.Merijn Brand
> Nicholas Clark <ni...@ccl4.org> writes:
> >
> >IIRC I've always just done it by hand by editing config.sh
> >I think if you run Configure interactively you can actually rejig the
> >architecture name in the answer to one of the questions.
>
> I always build with -g and then strip if I want one without.
No harm done there
> -g isn't supposed to change the generated code (RMS gets livid
> if it does ...)
>
> The real issue is whether perl is build with -DDEBUGGING which would
> be different code.
Soooo true.
> I have always thought that -g turning on -DDEBUGGING was okay as
> a default but a bit clumsy.
isn't it the other way round? -DDEBUGGING turns on -g?
whatever it is, most people want neither or both
(Nick, you do not categorize under most)
> >There seem to be three options
> >
> >0: as is - -g doesn't change archname
> >1: -g always changes archname
> >2: Configure asks whether -g should change the archname
>
> s/-g/-DDEBUGGING/ ?
yes.
Nick Ing-Simmons
>> I have always thought that -g turning on -DDEBUGGING was okay as
>> a default but a bit clumsy.
>
>isn't it the other way round? -DDEBUGGING turns on -g?
>whatever it is, most people want neither or both
>(Nick, you do not categorize under most)
I am certain that
./Configure -der ... -Doptimize="-O2 -g"
gives me -DDEBUGGING.
I haven't tried it the other way round in a long time if ever.
The above is from my ~/p5/config script and I always get a debuuging
perl. It has also irritated me often enough when I want a fast
perl which I can still backtrace with gdb to be sure that -g
turns on -DDEBUGGING.
My €0.02 would be to turn that feature off.
The other way round -DDEBUGGING turn on -g would be okay by me
- provided it did not turn off -O2. I have been routinely
building everything -O2 -g for years and know its limitations
and quirks.
Tim Bunce
> H.Merijn Brand <h.m....@hccnet.nl> writes:
> >> I have always thought that -g turning on -DDEBUGGING was okay as
> >> a default but a bit clumsy.
> >
> >isn't it the other way round? -DDEBUGGING turns on -g?
> >whatever it is, most people want neither or both
> >(Nick, you do not categorize under most)
>
> I am certain that
>
> ./Configure -der ... -Doptimize="-O2 -g"
>
> gives me -DDEBUGGING.
>
> I haven't tried it the other way round in a long time if ever.
> The above is from my ~/p5/config script and I always get a debuuging
> perl. It has also irritated me often enough when I want a fast
> perl which I can still backtrace with gdb to be sure that -g
> turns on -DDEBUGGING.
>
>
> The other way round -DDEBUGGING turn on -g would be okay by me
> - provided it did not turn off -O2. I have been routinely
> building everything -O2 -g for years and know its limitations
> and quirks.
FWIW, I agree entirely.
Tim.
H.Merijn Brand
I will investigate the ossibility to do this simple
> Tim.