} libpcre.la's, libpcreposix.la's (just noticed my horrible typo in
} the previous email) and libpcrecpp.la's CFLAGS were patched, so the
} respective objects were not compiled with position independent code.
That's not necessarily true. It could be that some of the object
files were compiles with -fpic and some weren't, or -- more likely, in
my view -- the object files weren't compiled with -fpic but the final
link step (gcc -shared) lacked the -fpic flag and needs it for some
reason.
} I don't have the full output and I already patched gentoo's libpcre,
} but the bug that I mentioned in the original email shows what
} happened without that patch:
}
https://bugs.gentoo.org/show_bug.cgi?id=182534
It shows the following commandline:
} x86_64-pc-linux-gnu-gcc -shared -o pcre.so pcre..o -L/usr/lib64 /usr/lib64/libpcre.a -ldl -lnsl -lncurses -lm -lc
Is this really right?? pcre..o, with two dots? pcre.so, rather than
libpcre.so? Compiling a shared-object library from a static library?
I've never seen sutff like this before. It's certainly quite
different from what I see on goobuntu. Is gentoo really so different?
It's also confusing because pcre uses libtool, which puts all its
outputs in the .libs directory, and I don't see that here.
I think we're really going to need more information to track down
what's going on here. It sounds like your patch was pretty simple.
Can you unapply it, run make (or, better, make -k) and include the
full output? Including your config.log file (from after you ran
./configure) might be helpful too.
craig
