> On Mon, Mar 17, 2003 at 08:47:35AM -0600, Bruce Winter wrote: > > > Rather, I believe there's no support for .ph files in > Module::ScanDeps. > > > Patches welcome on that adrea. > > > > But even if we made it smart enought to look for .ph requires, > I don't think > > it would find requires within eval tests. The SerialPort > author does evals > > in a loop so he can try various different locations for the .ph files. > > Correct. So there must always be a mechanism for hand-adding stuff. > But of course, M::SD can also include module-specific heuristics, > which I'll do so in the next release for SerialPort.
I think hand-adding the exceptions is a fine solution. I can't imagine how you would come up with heuristics to unwind evaled code. But then again, I'm not sure how you did that Tk Widget trick :) > > perl -V shows this is in the INC path: > > > > /usr/local/lib/perl5/site_perl/5.8.0/i686-linux > > > > so I think a -A asm/termios.ph would do it. > > Sounds like a plan. Okay. :) Great! > > Gave the latest patchset a spin. No problems found, but it didn't fix > > enable GD loading: > > I suspect there are other related .so files that I will need to > load. I'll > > dig into this further and let you know. > > ldd says so here: > > libpng.so.5 => /usr/local/lib/libpng.so.5 (0x28142000) > libz.so.2 => /usr/lib/libz.so.2 (0x28165000) > libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x28172000) > libm.so.2 => /usr/lib/libm.so.2 (0x28190000) > libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x281ab000) > > so you may wish to -l all of them in addition to libgd. > > One neat feature would be to call ldd automagically and include them.. I think I have this working now! At least it loads on the same box I compile it on. Now I've got a different problem when I run the resulting binary on a different linux box. I get this message: [EMAIL PROTECTED] bin]$ /projects/public/a.out /projects/public/a.out: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /projects/public/a.out) In fact, I'll get this even with the simplest of script. I tried it on both a RH 5.2 and RH 7.2 box. I think the newer libraries I have on the RH 8.0 box I compiled it on are somehow not compatable? I tried various combinations of -l files, but I think this happens right away, before the pp generated binary can do anything. > > > If somebody on Win32 can help testing / porting the shlib support to > > > that platform, I'll gladly merge it earlier. > > > > I can give Win32 a spin also, except I think the latest version that PPM > > gave me there was 0.63, so the patches wouldn't apply. What is > the best way > > to check version number? > > Well if you have MSVC++ (which you will need to compile shlib support > anyway) just download the snap and compile it there. > > If you don't... I'll try putting up a binary for you tomorrow. 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. Thanks! Bruce
