> > > You mean it gets extracted as asm/termios.pm? That's most > unfortunate. > > > I'll test it a bit more. > > > > Sorry, I should have been clearer. The name is an random generated 8 > > character name with a .pm suffix. I found which it was by > doing a grep for > > TERMIOS, a string in that asm/termios.ph member. > > And anyway it's been fixed by the new Module::ScanDeps, the > extension is not a problem. :-)
Yes indeed. Works great now, without any -M option! > > > > I discovered I can run pp binaries I compile on my Red Hat 7.2 > > > box on my Red > > > > Hat 8.0 box, but not the other way around, due to the GLIBC > > > errors above. > > > That's to be expected. Glad to hear that the other way works. > > Would there be any way I could run pp on the RH 8 box so that > the binaries > > are backward compatable? Maybe by somehow using the older > glibc libraries?? > > You can only do that by explicitly linking against an older libc > when you build your perl, iirc. Well hmmm. Maybe I could build a special pp only perl binary. Or maybe there is not disadvantage to the older glibc lib so I should do it by default? So I guess this is a general problem for linux binaries that I hadn't realized before. Too used to windows .exe files I suppose :) On linux, binaries must be rebuilt for each platform, or to the oldest version of whatever libs they use. I don't recall this as a problem when I test drove the ActiveState perlapp, so maybe that is what they did. > > Thanks, I ran that patch then re-installed. It accepts the -l > option now, > > but I'm not sure it helps. I still get this msg: > > This is with MinGW, or MSVC++? I'm using the windows binaries you built, distributed via nmake MakeFile.pl etc. Bruce
