Yes I build project static. I was doing rename files, the problem remains. only copying function boot_mro() etc. of the file ext/mro/mro.c in file mro.c project builds.
This feature of work the compiler XLS on z/OS. ------------------------------------------------------------------------ Yaroslav Kuzmin Developer C/C++ ,z/OS , Linux 3 Zhukovskiy Street · Miass, Chelyabinsk region 456318 · Russia Tel: +7.922.2.38.33.38 Email: [email protected] Web: www.rocketsoftware.com ________________________________________ От: Nicholas Clark <[email protected]> от имени Nicholas Clark <[email protected]> Отправлено: 10 июня 2014 г. 23:44 Кому: Leon Timmermans Копия: Yaroslav Kuzmin; perl-mvs; Perl5 Porters Тема: Re: modul mro On Tue, Jun 10, 2014 at 05:59:56PM +0200, Leon Timmermans wrote: > On Tue, Jun 10, 2014 at 12:10 PM, Yaroslav Kuzmin < > [email protected]> wrote: > > > Also cross function calls in file ext/mro/mro.c in function boot_mro() > > call function Perl_mro_register(), but function boot_mro() passed as an > > argument to a function Perl_newXS() in file op.c > > > > just copying the entire file ext/mro/mro.c in file mro.c solves the > > problem. > > > > Your description is rathre vague. I agree with «in file ext/mro/mro.c in > function boot_mro() call function Perl_mro_register()», but what I'm not > certain what you mean with «but function boot_mro() passed as an argument > to a function Perl_newXS() in file op.c». AFAICT, boot_mro is only referred > by Dynaloader, which looks it up dynamically. Except that your ar examples > suggest you're trying to build a static perl. I don't know the static > building process well, I can imagine this kind of ordering issue arising. I > would guess the real solution is in fixing the build process. If it's a static build, then based on previous experience of "less than awesome" toolchains, the problem will be that there are two files named mro.o, and the toolchain can't cope. I think that the easiest way to confirm whether this is a problem is to rename the top level mro.c, replacing the references to mro.c and mro$(OBJ_EXT) in Makefile.SH with a different name. eg mv mro.c notmro.c and then this: diff --git a/MANIFEST b/MANIFEST index 2b30273..f3b832a 100644 --- a/MANIFEST +++ b/MANIFEST @@ -4271,3 +4271,3 @@ mkppport A script that distributes ppport.h mkppport.lst List of extensions that need a ppport.h -mro.c Method Resolution Order code +notmro.c Method Resolution Order code myconfig.SH Prints summary of the current configuration diff --git a/Makefile.SH b/Makefile.SH index 8c6221a..8779f77 100755 --- a/Makefile.SH +++ b/Makefile.SH @@ -474,3 +474,3 @@ h = $(h1) $(h2) $(h3) $(h4) $(h5) $(h6) -c1 = av.c scope.c op.c doop.c doio.c dump.c gv.c hv.c mg.c reentr.c mro.c perl.c +c1 = av.c scope.c op.c doop.c doio.c dump.c gv.c hv.c mg.c reentr.c notmro.c perl.c c2 = perly.c pp.c pp_hot.c pp_ctl.c pp_sys.c regcomp.c regexec.c utf8.c sv.c @@ -484,3 +484,3 @@ obj0 = op$(OBJ_EXT) perl$(OBJ_EXT) obj0mini = perlmini$(OBJ_EXT) opmini$(OBJ_EXT) miniperlmain$(OBJ_EXT) -obj1 = $(madlyobj) $(mallocobj) gv$(OBJ_EXT) toke$(OBJ_EXT) perly$(OBJ_EXT) pad$(OBJ_EXT) regcomp$(OBJ_EXT) dump$(OBJ_EXT) util$(OBJ_EXT) mg$(OBJ_EXT) reentr$(OBJ_EXT) mro$(OBJ_EXT) keywords$(OBJ_EXT) +obj1 = $(madlyobj) $(mallocobj) gv$(OBJ_EXT) toke$(OBJ_EXT) perly$(OBJ_EXT) pad$(OBJ_EXT) regcomp$(OBJ_EXT) dump$(OBJ_EXT) util$(OBJ_EXT) mg$(OBJ_EXT) reentr$(OBJ_EXT) notmro$(OBJ_EXT) keywords$(OBJ_EXT) obj2 = hv$(OBJ_EXT) av$(OBJ_EXT) run$(OBJ_EXT) pp_hot$(OBJ_EXT) sv$(OBJ_EXT) pp$(OBJ_EXT) scope$(OBJ_EXT) pp_ctl$(OBJ_EXT) pp_sys$(OBJ_EXT) If your build works with that change, then the problem is that the toolchain can't cope with two files named mro.c. In which case, the best fix is adapting the code from ext/Hash-Util/Makefile.PL into ext/mro/Makefile.PL, so that it use a different name for ext/mro/mro.o. Nicholas Clark
