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 tableThe .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-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|