On Wed, Jul 30, 2008 at 7:52 AM, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Tue, Jul 29, 2008 at 11:17:33PM +1000, Brendan O'Dea <[EMAIL PROTECTED]> > wrote: >> I think that you have some other problem. -L<path> -lperl will search >> at compile time for libperl.so or libperl.a in <path> before it >> searches /usr/lib. > > No, it will srearch for libperls.o *first* in all directories and then for > libperl.a. If the alternative perl is built without a shared library, then > the debuian one will be picked up first.
That is not the way that any linker I have ever used works, and the current unstable Debian linker works pretty much exactly as I would expect. To test this, I picked a simple function from libperl, Perl_my_snprintf which could be used to demonstrate which library is selected by the linker. See attached local_libperl.c which provides an implementation of this function, operating in a way that allows it to be clearly distinguished from the packaged library, and test.c which calls the function. A transcript follows: $ ls -l /usr/lib/libperl.* -rw-r--r-- 1 root root 5424738 2008-07-17 02:32 /usr/lib/libperl.a lrwxrwxrwx 1 root root 15 2008-07-30 21:05 /usr/lib/libperl.so -> libperl.so.5.10 lrwxrwxrwx 1 root root 17 2008-07-30 20:40 /usr/lib/libperl.so.5.10 -> libperl.so.5.10.0 -rw-r--r-- 1 root root 1364380 2008-07-17 02:32 /usr/lib/libperl.so.5.10.0 $ cc -c local_libperl.c $ ar rv /tmp/libperl.a local_libperl.o ar: creating /tmp/libperl.a a - local_libperl.o $ cc test.c -o debian -lperl $ cc test.c -o local -L/tmp -lperl $ ./debian Debian libperl $ ./local local libperl So on my machine, updated to latest unstable and with libperl-dev installed, linking with "-L<path> -lperl" selects the library from <path>, even with /usr/lib contains both .so and .a. >> If by "windows process emulation?" you are referring to threads, I >> suggest that you go read the POSIX standard. > > That's just a stupid ad-hominem :( I know the posix standard very well, > but it is irrelevant: perl doesn't offer threads, what it does is emulate > processes *using* threads (and it uses pthreads on e.g. debian to do that). In the context of a response to the assertion that I had made some "extremely bad choices for configuration", and what appeared to be a rather naive assertion about the nature of ithreads, I believe that I was fairly restrained. > When you create a perl thread, then perl actually creates a pseudo-process by > copying the *whole* perl interpreter. There is no shared "address space", > and> the whole thing was created to emulate processes on windows, thus process > emulation. I am intimately aware how Perl threading works. I can assure you that it was not created to emulate processes on Windows. There can be shared address space when required (see threads::shared). The major reason for enabling ithreads however was not primarily to allow people to "use threads", but more to allow perl to be embedded into threaded programs (mod_perl 2.0 for example required perl to be compiled with ithreads). --bod
local_libperl.c
Description: Binary data
test.c
Description: Binary data
