Re: [squid-users] Solaris/OpenSSL/MD5 Issues

Greetings all,

Amos wrote:
> Where else outside client_side_reply.cc did you remove
> #if ESI / #endif code? you said 'modules' so I am assuming
> the problem came up elsewhere later.

After disabling the block in client_side_reply.cc the build ended
with:

ld: warning: file /usr/sfw/lib/amd64/libstdc++.so: attempted multiple inclusion of file
Undefined first referenced
 symbol in file
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/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/export/home/randy/Download/squid-3.0.RC1/src'
gmake: *** [all] Error 2


Then in cache_cf.cc I commented out the

#if ESI
#include "ESIParser.h
#endif

section, rebuilt, and g++ said:

        if g++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\"/usr/local/squid/etc/squid.conf\" -I. -I. -I../include -I. -I. -I../include -I../include -I../lib/libTrie/include -I/usr/include/libxml2 -I/usr/local/include -Wall -Wpointer-arith -Wwrite-strings -Wcomments -D_REENTRANT -pthreads -DSOLARIS2=11 -O3 -m64 -march=opteron -mcpu=opteron -mtune=opteron -msse3 -m3dnow -mfpmath=sse -pthreads -MT cache_cf.o -MD -MP -MF "$depbase.Tpo" -c -o cache_cf.o cache_cf.cc; \
        then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi
In file included from cache_cf.cc:2564:
cf_parser.h: In function `int parse_line(char*)':
cf_parser.h:1145: error: `ESIParser' has not been declared
cf_parser.h:1145: error: `Type' undeclared (first use this function)
cf_parser.h:1145: error: (Each undeclared identifier is reported only once for each function it appears in.)
cf_parser.h: In function `void dump_config(StoreEntry*)':
cf_parser.h:1950: error: `ESIParser' has not been declared
cf_parser.h:1950: error: `Type' undeclared (first use this function)
cf_parser.h: In function `void free_all()':
cf_parser.h:2373: error: `ESIParser' has not been declared
cf_parser.h:2373: error: `Type' undeclared (first use this function)
gmake[2]: *** [cache_cf.o] Error 1
gmake[2]: Leaving directory `/export/home/randy/Download/squid-3.0.RC1/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/export/home/randy/Download/squid-3.0.RC1/src'
gmake: *** [all] Error 2

so then, in cf_parser.h I commented out the 12 #if ESI/#endif blocks
and ran gmake again and end up with a binary that starts but when
accessed it says:
FATAL: Received Segment Violation...dying.
2007/11/11 00:02:42| storeDirWriteCleanLogs: Starting...
2007/11/11 00:02:42| WARNING: Closing open FD 13
2007/11/11 00:02:42| Finished. Wrote 1 entries.

I'm going to try and figure out how cf_parser.h gets built so I can
remove those ESI bits from the source and as an exercise in
learning more about autotools. I sure wish I could be more helpful
but I've never really had to understand autotools. I don't use
them at work and up until now if I had any problems with them, I'd
simply upgrade the tools if I was trying to build some open source
distro. I hope my lack of understanding of the tools isn't leading
you all on a wild goose chase.

Kind regards



--
Randall D. DuCharme (Radio AD5GB)
Powered by OpenSolaris!
http://www.opensolaris.org

 --- On Sun 11/11, Amos Jeffries < squid3@treenet.co.nz > wrote:
From: Amos Jeffries [mailto: squid3@treenet.co.nz]
To: radio-ad5gb@excite.com
     Cc: rousskov@measurement-factory.com, squid-dev@squid-cache.org, guido.serassio@acmeconsulting.it
Date: Sun, 11 Nov 2007 23:24:43 +1300
Subject: Re: [squid-users] Solaris/OpenSSL/MD5 Issues

Randall DuCharme wrote:>>> Undefined first referenced>>> symbol in file>>> esiEnableProcessing(HttpReply*) client_side_reply.o>>> esiProcessStream(clientStreamNode*, ClientHttpRequest*, HttpReply*, StoreIOBuffer) client_side_reply.o> >> 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> > Nothing. I never hits the error. Bizarre. Just as a hack I tried> commenting out the blocks of code inside the #if ESI/#endif sections> of the affected modules and was able to get a binary. It crashes> every time it's accessed accessed however though that may be yet> another issue.> Well, the error was meant to prove whether or not the esi* function calls in client_side_reply.cc were even compiled. Apparently not. Yet something is pulling the symbols into the linker.Where else outside
client_side_reply.cc did you remove #if ESI / #endif code? you said 'modules' so I am assuming the problem came up elsewhere later.After Guidos comment, I think we should do with a diff of a good working include/autoconf.h against yours and see whats up.Guido: are you able to supply the working version please?Amos

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Received on Sun Nov 11 2007 - 08:37:43 MST