try compiling without string.h... You may not have noticed the extra "else if" I
added to the par_setup_libpath function. I call strstr() in an effort to avoid
adding to the libpath if it already contains the path we're adding. While strstr()
would not work well if we were adding say "/lib" to the libpaths (it would falsely
match /usr/lib, /usr/X11/lib, etc), I figured since we're adding something like
/tmp/par-username/cache-asd8f76as8d7f6.... that it would be unique enough
that the strstr() function would suffice.
A couple of other things while I have your attention:
1. When I use '-l somelib' with pp, pp currently adds libsomelib.so to the par.
On linux, at least, libsomelib.so is probably a symlink to libsomelib.so.1 which
is probably a symlink to libsomelib.so.1.2.... Shouldn't pp follow these symlinks
and add the real file (libsomelib.so.1.2) to the par rather than libsomelib.so?
I had to use '-l libsomelib.so.1.2' as a work around, but it'd be nice if pp chased
these symlinks for us....
2. In PAR-0.85_01, you added some patches to myldr/Makefile.PL in an effort
to fix gentoo and debian installs.... Well, it breaks things on RedHat. On my
install, -lperl is still required when linking par, but it refers to libperl.a which is a
static lib. Using the existence of -lperl in ldopts to set $dynperl won't, therefore,
work. I haven't looked at it enough to offer any other solutions, though.
Thanks for all your hard work! -Rob
Autrijus Tang wrote:
On Wed, Nov 17, 2004 at 05:31:12PM -0700, Robert Wyrick wrote:
I've created a patch that fixed the problem for me.....
Thanks, applied, except for the first chunk that includes <string.h> -- the <perl.h> in the main programs should provide the correct strlen() include, no?
Cheers,
/Autrijus/
