Am 02.05.2016 um 20:35 schrieb Andy Wang:
On 05/02/2016 12:42 PM, Rainer Jung wrote:
Am 02.05.2016 um 19:07 schrieb Huang, Jinhui (OST):
Hi, Rainer:
I checked the 32/64 Bit issue on PCRE first. I found
/usr/local/apache2/pcre/lib/libpcre.a: current ar archive, 32-bit
symbol table
/usr/local/apache2/pcre/lib/libpcreposix.a: current ar archive,
32-bit symbol table
The .so (shared libraries) look fine, the .a (static libraries) not.
They are 32 Bit and you can't link a 64 bit binary against them. By
default, the linking should happen against the .so (building dynamically
linked stuff). If you want to make sure, it'd be better to rename the .a
file to .a_ or similar, so they wont get used.
Why pcre has build the .a files only as 32 bit and didn't respect your
CC setting I don't know but shouldn't matter for now.
Are you basing that on the file command output? Keep in mind the symbol
table size is not dependent on the bitwidth of the binaries in the
archive but rather the size of of the ar archive itself.
From ar man page:
-S When building the archive symbol table, force the use
of the 64-bit capable symbol table format. By default,
the 32-bit format is used for all archives smaller
than 4GB, and the larger format is used for larger
archives that exceed the 32-bit limit.
Yes, sorry, I just referred to "/usr/local/apache2/pcre/lib/libpcre.a:
current ar archive, 32-bit symbol table". But since the OP shouldn't
IMHO try to link against the .a files, it doesn't actually matter.
The compile error doesn't appear related to pcre though. It looks to be
more still an openssl related problem.
Agreed.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
