Re: /bzr/squid3/trunk/ r10096: Bug 2778: fix linking issues using SunCC
Ok, I will asap. Regarding the #defines: autoconf does it, so it's probably the most portable way, and it doesn't hurt anyways. I wouldn't go as far as defining this in a style guide, but converting stuff as it is touched may help portability-wise. the first input to me to do this was because sun cpp complained about non-constant symbols as I converted from #ifdef to #if. It was not the root cause, but I decided to let it in for the above reasons. On 11/7/09, Amos Jeffries squ...@treenet.co.nz wrote: Francesco Chemolli wrote: revno: 10096 committer: Francesco Chemolli kin...@squid-cache.org branch nick: trunk timestamp: Fri 2009-11-06 17:22:16 +0100 message: Bug 2778: fix linking issues using SunCC SunCC doesn't handle inline extern functions, and misses some duplicate code detection features gcc has; as a result squid-specific operator new and operator delete get defined multiple times and fail linking. Implemented a compiler-specific workaround by de-inlining the code. Improved Solaris OS detection logic (and dropped _SQUID_SUNOS_ which was not used anyways) modified: compat/compat.h compat/os/solaris.h compat/osdetect.h include/SquidNew.h src/SquidNew.cc Oops. _SQUID_SUNOS_ is used. _SQUID_SUN_ was the unused one. Please also revert the bit changing compat/compat.h. It's not relevant. Also, were the added 1's in osdetect.h actually required? There may be many other places in the code hitting the same problem if so. (I'm now converting my old pre-compiler test app into unit-tests so we can easily identify this) Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.14 -- /kinkie
Re: /bzr/squid3/trunk/ r10096: Bug 2778: fix linking issues using SunCC
Kinkie wrote: Ok, I will asap. Regarding the #defines: autoconf does it, so it's probably the most portable way, and it doesn't hurt anyways. I wouldn't go as far as defining this in a style guide, but converting stuff as it is touched may help portability-wise. the first input to me to do this was because sun cpp complained about non-constant symbols as I converted from #ifdef to #if. It was not the root cause, but I decided to let it in for the above reasons. Nevermind. Halfway through the unit-tests to check for viability I re-discovered we do indeed have to define to one, zero, or undefined for #if to work. Amos On 11/7/09, Amos Jeffries squ...@treenet.co.nz wrote: Francesco Chemolli wrote: revno: 10096 committer: Francesco Chemolli kin...@squid-cache.org branch nick: trunk timestamp: Fri 2009-11-06 17:22:16 +0100 message: Bug 2778: fix linking issues using SunCC SunCC doesn't handle inline extern functions, and misses some duplicate code detection features gcc has; as a result squid-specific operator new and operator delete get defined multiple times and fail linking. Implemented a compiler-specific workaround by de-inlining the code. Improved Solaris OS detection logic (and dropped _SQUID_SUNOS_ which was not used anyways) modified: compat/compat.h compat/os/solaris.h compat/osdetect.h include/SquidNew.h src/SquidNew.cc Oops. _SQUID_SUNOS_ is used. _SQUID_SUN_ was the unused one. Please also revert the bit changing compat/compat.h. It's not relevant. Also, were the added 1's in osdetect.h actually required? There may be many other places in the code hitting the same problem if so. (I'm now converting my old pre-compiler test app into unit-tests so we can easily identify this) Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.14 -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.14
Re: Issue compiling last 3.1 squid in 64-bit platform
rena...@flash.net.br wrote: Thanks for your reply, Amos! As I am a newbie, I thought I would not help in the -dev list. Should I move this thread there? Moved. I'm using the last squid-3.1.0.14-20091110 now and I'm still getting the same compiling error in Slackware-64 (13.0), even in other servers. Am I missing something? Did you erase the old build completely and start fresh with the new code? If so could you please send in a copy of the config.log generated during the build. It should be the directory where you ran configure to start things off. And what, if any, options did you pass to configure? Amos Thank you again for your time trying to help me! On Mon, 9 Nov 2009 14:02:51 -0200 (BRST), rena...@flash.net.br wrote: Greetings! I'm trying to test some new features of the 3.1 Squid Brand and I just tried to compile the last snapshot (squid-3.1.0.14-20091109) on Slackware 13.0 64-BIT, with an Intel Xeon server (64-bit), gcc 4.3.3. Even not using any special configure options, I always get the error: (...) depbase=`echo DiskIO/DiskDaemon/DiskDaemonDiskIOModule.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\/usr/local/squid/etc/squid.conf\ -DDEFAULT_SQUID_DATA_DIR=\/usr/local/squid/share\ -DDEFAULT_SQUID_CONFIG_DIR=\/usr/local/squid/etc\ -I.. -I../include -I../src -I../include -I/usr/local/include -I../lib -I../lib/libLtdl -I../src -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -D_REENTRANT -g -O2 -MT DiskIO/DiskDaemon/DiskDaemonDiskIOModule.o -MD -MP -MF $depbase.Tpo -c -o DiskIO/DiskDaemon/DiskDaemonDiskIOModule.o DiskIO/DiskDaemon/DiskDaemonDiskIOModule.cc \ mv -f $depbase.Tpo $depbase.Po rm -f libDiskDaemon.a /usr/bin/ar cru libDiskDaemon.a DiskIO/DiskDaemon/DiskdFile.o DiskIO/DiskDaemon/DiskdIOStrategy.o DiskIO/DiskDaemon/DiskDaemonDiskIOModule.o ranlib libDiskDaemon.a make[3]: *** No rule to make target `-lpthread', needed by `all-am'. Stop. make[3]: Leaving directory `/home/sources/squid-3.1.0.14-20091109/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sources/squid-3.1.0.14-20091109/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sources/squid-3.1.0.14-20091109/src' make: *** [all-recursive] Error 1 If I disable the threads option in the configure line, I get: (...) depbase=`echo globals.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\/usr/local/squid/etc/squid.conf\ -DDEFAULT_SQUID_DATA_DIR=\/usr/local/squid/share\ -DDEFAULT_SQUID_CONFIG_DIR=\/usr/local/squid/etc\ -I.. -I../include -I../src -I../include -I/usr/local/include -I../lib -I../lib/libLtdl -I../src -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -MT globals.o -MD -MP -MF $depbase.Tpo -c -o globals.o globals.cc \ mv -f $depbase.Tpo $depbase.Po make[3]: *** No rule to make target `-lm', needed by `ufsdump'. Stop. make[3]: Leaving directory `/home/sources/squid-3.1.0.14-20091109/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sources/squid-3.1.0.14-20091109/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sources/squid-3.1.0.14-20091109/src' make: *** [all-recursive] Error 1 Did anyone have this problem, too? Is this a 64-bit related issue? This server has 16GB RAM, so I need to use 64-bit, right? Any ideas on how to solve this? I did some research in the maillist and google, but didn't find the same issue. Thank you all very much!! Firstly, report code problems in beta release code to squid-dev mailing list so the devs can find out about it. I think the fix is now ported. Please try the next bundle (20091110) when its ready in a few hours. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.14
Re: Issue compiling last 3.1 squid in 64-bit platform
tis 2009-11-10 klockan 18:23 +1300 skrev Amos Jeffries: make[3]: *** No rule to make target `-lpthread', needed by `all-am'. This is the XTRA_LIBS confusion currently being fixed up in trunk. XTRA_LIBX must only be added in LDADD rules, not the CUSTOM_LIBS which is also a dependency.. Regards Henrik
