> > I just installed the 0.66 release (sorry I didn't get a chance
> to test it
> > out sooner) and tried this out with -M asm/termios.ph,  but the 'use
> > SerialPort.pm' still fails.   I DO see the file unziped into
> /tmp, but as a
> > .pm file.  I'm not sure how you work the magic to get those
> modules found by
> > the correct name, but I don't think it is working in this case.
>
> 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.

> > 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??

> > > Sorry, I don't have any windows C compilers installed here.  I'd
> > > by happy to
> > > test out your recent updates once you get an updated binary.
> >
> > When I installed 0.66 on my windows box, I did not get the 'try the
> > experimental shlib' option, so I wasn't able to test this yet.  Trying
> > the -l option seemed to invoke -log instead.
>
> The problem is that the shlib option uses <unistd.h> which is not
> present in MSVC++, so I disabled it altogether; you can download
> the 'patch.exe' from GNU/Win32 or Cygwin and apply it manually:
>
>     % patch -N -p0 < patches/shlib.diff

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:

 Can't locate loadable object for module xyz

I tried a couple of different modules with this:

 set myL=-l c:/perl580/site/lib/auto/Win32/OLE/OLE.dll
 set myL=%myL% -l c:/perl580/site/lib/auto/Win32/setupsup/setupsup.dll
 set PAR_DEBUG=1
 call pp.bat %myM% %myL% -o mhe.exe mh

The resulting .exe file does get bigger, but when I run it, I don't see
errata indicating those .dll files are getting extracted.  Here is the last
of that errata, where the .dll files seem to be listed:

Unpacking file "05272da8/PAR/Heavy.pm"...
Unpacking file "07f6ae46/auto/Compress/Zlib/autosplit.ix"...
Unpacking file "2cf762b6/auto/IO/IO.dll"...
Unpacking file "2d5ebc01/auto/Cwd/Cwd.dll"...
Unpacking file "7d31881c/auto/Fcntl/Fcntl.dll"...
Unpacking file "9290d57e/auto/Compress/Zlib/Zlib.dll"...
Unpacking file "cf12a53d/auto/List/Util/Util.dll"...


Bruce


Reply via email to