Randall DuCharme wrote:
>
> Amos wrote
>>> Okay. That looks like another seperate problem than MD5.
>>> For some reason you have "-Wl,-R -Wl,/usr/sfw/lib/amd64"
>>> twice times at the end of the g++ parameters, that looks to be
>>> the problem. Are you manually setting those flags or leaving
>>> to the autotools?
>
>> I was setting -L and -R flags in in the LDFLAGS env variable
>> during configure since with GCC I often have problems with the
>> runtime linker not being able to find libraries and trying to
>> use 32 bit libraries when doing a 64 bit build if I don't set
>> them. I have removed all -L and -R paths (and I do not set
>> LD_LIBRARY_PATH on Solaris) yet I still end up with the duplicate
>> linker arguments. I'm off to see if I can figure out how this is
>> happening.
>
> Ok this is strange. It looks like it's trying to compile ESI
> specific support in yet I've not done --enable-esi. In autoconf.h
> "#define ESI 0" is present. I've removed the -Werror flag for now
> so the multiple inclusion warning shouldn't be stopping anything:
>
> ld: warning: file /usr/sfw/lib/amd64/libstdc++.so: attempted multiple inclusion of file
> Undefined first referenced
> symbol in file
> esiEnableProcessing(HttpReply*) client_side_reply.o
> esiProcessStream(clientStreamNode*, ClientHttpRequest*, HttpReply*, StoreIOBuffer) client_side_reply.o
> esiStreamRead(clientStreamNode*, ClientHttpRequest*) client_side_reply.o
> esiStreamDetach(clientStreamNode*, ClientHttpRequest*) client_side_reply.o
> esiStreamStatus(clientStreamNode*, ClientHttpRequest*) client_side_reply.o
> ESIParser::Type cache_cf.o
> ld: fatal: Symbol referencing errors. No output written to ufsdump
> collect2: ld returned 1 exit status
> gmake[2]: *** [ufsdump] Error 1
> gmake[2]: Leaving directory `/export/home/randy/Download/squid-3.0.RC1.patched/src'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/export/home/randy/Download/squid-3.0.RC1.patched/src'
> gmake: *** [all] Error 2
>
>
What does adding a
#if ESI
#error Something defined ESI!
#endif
Do to the compile process if its added near the top of
src/client_side_reply.cc
It may be a mater of making ESI use a different bounding macro (USE_ESI).
Amos
Received on Sat Nov 10 2007 - 22:18:32 MST
This archive was generated by hypermail pre-2.1.9 : Sat Dec 01 2007 - 12:00:05 MST