Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perl -MO=BACKEND file.pl appears to not function in 5.005_62 #787

Closed
p5pRT opened this issue Oct 25, 1999 · 4 comments
Closed

perl -MO=BACKEND file.pl appears to not function in 5.005_62 #787

p5pRT opened this issue Oct 25, 1999 · 4 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Oct 25, 1999

Migrated from rt.perl.org#1714 (status was 'resolved')

Searchable as RT1714$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 25, 1999

From bkuhn@ebb.org

My humblest apologies if I am reporting something that is already known. I
didn't see anything go by on p5p about this, but I must admit that I do not
read some threads very closely.

I have been having a problem using Backends via the O module in 5.005_62. I
have reconfigured the source and attempted to get everything working from
the build directory. However, right after compiling, and making all tests
(successfully), the following occurs​:

$ ./perl -I lib -MO=Bytecode t/base/cond.t > x
t/base/cond.t syntax OK
$ ls -l x
-rw------- 1 bkuhn bkuhn 0 Oct 26 02​:39 x
$ cat x
$ ./perl -I lib -MO=Terse t/base/cond.t
t/base/cond.t syntax OK
$

On 5.005_61, configured the same way on the same system, both perl commands
produce copious output.

I discovered the problem while working on my own backend (which works fine
with 5.005_61, but fails in 5.005_62).

I have confirmed that the O module is calling compile() from the appropriate
Backend module; however, it appears that the anonymous sub returned by said
Backend module *never* gets called.

This simple example exhibits it​:

place this file in foo/B/TestProblem.pm
###############################################################################
package B​::TestProblem;

sub compile {
  print "Got here\n";

  return sub { print "Never gets here\n"; }
}
1;
###############################################################################

Then try​:

$ perl5.00562 -Ifoo -MO=TestProblem some_script.pl
Got here
some_script.pl syntax OK
$ perl5.00561 -Ifoo -MO=TestProblem some_script.pl
Got here
some_script.pl syntax OK
Never gets here
$

I am sorry that I cannot give any more information on the specifics of the
problem, but I am still a bit unclear on the details of how the O module
interfaces back the B modules.

Thanks, and again, sorry if this is already a known bug.

Perl Info


Site configuration information for perl 5.00562:

Configured by bkuhn at Tue Oct 26 02:09:53 EDT 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 62) configuration:
  Platform:
    osname=linux, osvers=2.2.2, archname=i586-linux
    uname='linux atheist 2.2.2 #5 thu feb 25 00:45:59 est 1999 i586 unknown '
    config_args='-Dcc=/usr/local/bin/gcc -Dprefix=/usr/experimental -Doptimize=-DDEBUGGING -g -Dinstallprefix=/usr/experimental/Stow/perl-5.005_62 -Dldflags=-L/usr/lib -L/lib -L/usr/experimental/lib -L/usr/local/lib -Dlibperl=libperl.so -Duseshrplib=true -Dperladmin=bkuhn@ebb.org -Dcf_email=bkuhn@ebb.org -Ods'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='/usr/local/bin/gcc', optimize='-DDEBUGGING -g', gccversion=egcs-2.91.60 19981201 (egcs-1.1.1 release)
    cppflags='-Dbool=char -DHAS_BOOL -DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='/usr/local/bin/gcc', ldflags ='-L/usr/lib -L/lib -L/usr/experimental/lib -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=/lib/libc-2.0.7.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/experimental/lib/perl5/5.00562/i586-linux/CORE'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/lib -L/lib -L/usr/experimental/lib -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00562:
    lib
    /usr/experimental/lib/perl5/5.00562/i586-linux
    /usr/experimental/lib/perl5/5.00562
    /usr/experimental/lib/site_perl/5.00562/i586-linux
    /usr/experimental/lib/site_perl
    .


Environment for perl 5.00562:
    HOME=/home/bkuhn
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/home/bkuhn/Files/Graduate/University-of-Cincinnati/Thesis/Perl-Source/perl5.005_62
    LOGDIR (unset)
    PATH=/usr/experimental/bin:/home/bkuhn/bin:/usr/local/bin:/sbin:/usr/bin:/bin:/usr/bin/X11:/usr/TeX/bin:/usr/games:/usr/openwin/bin:.
    PERL_BADLANG (unset)
    SHELL=/bin/tcsh

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 26, 1999

From @gsar

On Tue, 26 Oct 1999 02​:54​:36 EDT, "Bradley M. Kuhn" wrote​:

My humblest apologies if I am reporting something that is already known. I
didn't see anything go by on p5p about this, but I must admit that I do not
read some threads very closely.

When it doubt, look up the p5p archives.

  http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-10/msg00652.html
  http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-10/msg00586.html

Sarathy
gsar@​ActiveState.com

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 3, 1999

From [Unknown Contact. See original ticket]

Gurusamy Sarathy wrote​:

On Tue, 26 Oct 1999 02​:54​:36 EDT, "Bradley M. Kuhn" wrote​:

My humblest apologies if I am reporting something that is already known. I
didn't see anything go by on p5p about this, but I must admit that I do not
read some threads very closely.

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-10/msg00652.html
http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-10/msg00586.html

Sarathy, my apologies. I did a search, but it clearly wasn't extensive
enough. :)

I read the threads in question. It appears that your STOP {} block solution
will make it possible to fix O.pm given the new -c behavior. Is this the
path that will be pursued?

(It wasn't clear from the thread in question if this would be the pursued
answer. Is somone working on this?)
--
  - bkuhn@​ebb.org - Bradley M. Kuhn - bkuhn@​gnu.org -
  http​://www.ebb.org/bkuhn

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 4, 1999

From @gsar

On Thu, 04 Nov 1999 01​:32​:25 EST, "Bradley M. Kuhn" wrote​:

I read the threads in question. It appears that your STOP {} block solution
will make it possible to fix O.pm given the new -c behavior. Is this the
path that will be pursued?

I think so, unless there are objections from others.

(It wasn't clear from the thread in question if this would be the pursued
answer. Is somone working on this?)

Since I proposed the idea, I think it's on my plate, but I wouldn't
mind getting a patch that implemented it. :-)

Doing it should be very simple--add a PL_stopav, push CVs onto it
just like it's done for INIT{}, and finally call_list(...,PL_stopav)
when returning from perl_parse(). The B​::* stuff will need
s/\bEND\b/STOP/g.

Sarathy
gsar@​ActiveState.com

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant