Re: undefined symbol: PL_stack_sp
[email protected] (Ingy dot Net) Fri, 18 Jul 2014 09:28:01 -0700
| Newsgroups | perl.inline |
|---|---|
| Message-ID | <CAHJtQJ6YZx4yynjEE2dy_J6VMwD+abd4fic9hhTaoNiTBpwKhw@mail.gmail.com> |
--047d7b2eda3bb2499d04fe7a3d8a Content-Type: text/plain; charset=UTF-8 Can someone turn this into an issue here https://github.com/ingydotnet/inline-c-pm/issues This type of discussion would do better there, as we'll get around to addressing it. Cheers On Thu, Jul 17, 2014 at 5:58 PM, <[email protected]> wrote: > > From: demerphq > Sent: Friday, July 18, 2014 7:40 AM > > > The above shows what goes wrong. Makemaker decides that PERL_LIB is >> "../../../../" instead of "/home/yorton/perl5/perlbrew/ >> perls/perl-5.14.4/lib/5.14.4" >> >> below is the diff of the two Makefiles, but the relevant part is as >> follows: >> >> -PERL_LIB = /home/yorton/perl5/perlbrew/perls/perl-5.14.4/lib/5.14.4 >> -PERL_ARCHLIB = /home/yorton/perl5/perlbrew/perls/perl-5.14.4/lib/5.14.4/ >> x86_64-linux >> +PERL_LIB = ../../../../lib >> +PERL_ARCHLIB = ../../../../lib >> >> I am guessing that MakerMaker decides that is being used as part of >> building perl, and that it should use it as the location for its header >> files. I know there is special logic in MakeMaker for this kind of purpose. >> > > I didn't know that. > If we could get a handle on precisely how to detect that this problem > might arise, then we could probably have Inline issue a warning that > "things might go awry, and if they do then you should move the script to a > different (sane) location". > > I tried running your demo script on Windows (as try.pl) in > C:/git_tree/perl/Porting with perl-5.14.0, EU-MM-6.62 and it still worked > fine for me. > Might there be a perlbrew component to this issue ? (I'm not at all > familiar with perlbrew. I just build my perls the old fashioned way and > call them via different shell/batch scripts.) > > I see that you're running EU-MM-6.57_05. If you think it's worth the > effort I guess you could see if updating to EU-MM-6.62 fixes the problem - > or do any other digging you think might be productive. (It's actually a bit > interesting.) > Otherwise we can just settle for the "Don't do that" solution ;-) > > Cheers, > Rob > --047d7b2eda3bb2499d04fe7a3d8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Can someone turn this into an issue here <a href=3D"h= ttps://github.com/ingydotnet/inline-c-pm/issues">https://github.com/ingydot= net/inline-c-pm/issues</a><br><br></div><div>This type of discussion would = do better there, as we'll get around to addressing it.<br> <br></div><div>Cheers<br></div></div><div class=3D"gmail_extra"><br><br><di= v class=3D"gmail_quote">On Thu, Jul 17, 2014 at 5:58 PM, <span dir=3D"ltr"= ><<a href=3D"mailto:[email protected]" target=3D"_blank">sisyphu= [email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><br> From: demerphq<br> Sent: Friday, July 18, 2014 7:40 AM<div class=3D""><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The above shows what goes wrong. Makemaker decides that PERL_LIB is ".= ./../../../" instead of "/home/yorton/perl5/perlbrew/<u></u>perls= /perl-5.14.4/lib/5.14.4"<br> <br> below is the diff of the two Makefiles, but the relevant part is as follows= :<br> <br> -PERL_LIB =3D /home/yorton/perl5/perlbrew/<u></u>perls/perl-5.14.4/lib/5.14= .4<br> -PERL_ARCHLIB =3D /home/yorton/perl5/perlbrew/<u></u>perls/perl-5.14.4/lib/= 5.14.4/<u></u>x86_64-linux<br> +PERL_LIB =3D ../../../../lib<br> +PERL_ARCHLIB =3D ../../../../lib<br> <br> I am guessing that MakerMaker decides that is being used as part of buildin= g perl, and that it should use it as the location for its header files. I k= now there is special logic in MakeMaker for this kind of purpose.<br> </blockquote> <br></div> I didn't know that.<br> If we could get a handle on precisely how to detect that this problem might= arise, then we could probably have Inline issue a warning that "thing= s might go awry, and if they do then you should move the script to a differ= ent (sane) location".<br> <br> I tried running your demo script on Windows (as <a href=3D"http://try.pl" t= arget=3D"_blank">try.pl</a>) in C:/git_tree/perl/Porting with perl-5.14.0, = EU-MM-6.62 and it still worked fine for me.<br> Might there be a perlbrew component to this issue ? (I'm not at all fam= iliar with perlbrew. I just build my perls the old fashioned way and call t= hem via different shell/batch scripts.)<br> <br> I see that you're running EU-MM-6.57_05. If you think it's worth th= e effort I guess you could see if updating to EU-MM-6.62 fixes the problem = - or do any other digging you think might be productive. (It's actually= a bit interesting.)<br> Otherwise we can just settle for the "Don't do that" solution= ;-)<br> <br> Cheers,<br> Rob <br> </blockquote></div><br></div> --047d7b2eda3bb2499d04fe7a3d8a--