Re: [RFC] Libraries usage in configure.in and Makefiles
On Wed, 2009-11-11 at 19:43 +1300, Amos Jeffries wrote: > Robert Collins wrote: > > On Wed, 2009-11-11 at 18:38 +1300, Amos Jeffries wrote: > >> > >> Why? > >> A: The squid binary is topping 3.5MB in footprint with many of the > >> small > >> tool stopping 500KB each. A small but substantial amount of it is > >> libraries inked but unused. > > > > Really? dynamically linked libraries should be . > > > > -Rob > > In the on-disk binary itself yes ... yet they load into memory under the > parent apps footprint. The pages for the libraries will be shared though, so it really doesn't matter. -Rob signature.asc Description: This is a digitally signed message part
Re: [RFC] Libraries usage in configure.in and Makefiles
Robert Collins wrote: On Wed, 2009-11-11 at 18:38 +1300, Amos Jeffries wrote: Why? A: The squid binary is topping 3.5MB in footprint with many of the small tool stopping 500KB each. A small but substantial amount of it is libraries inked but unused. Really? dynamically linked libraries should be . -Rob In the on-disk binary itself yes ... yet they load into memory under the parent apps footprint. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.14
Re: [RFC] Libraries usage in configure.in and Makefiles
On Wed, 2009-11-11 at 18:38 +1300, Amos Jeffries wrote: > > > Why? > A: The squid binary is topping 3.5MB in footprint with many of the > small > tool stopping 500KB each. A small but substantial amount of it is > libraries inked but unused. Really? dynamically linked libraries should be . -Rob signature.asc Description: This is a digitally signed message part
[RFC] Libraries usage in configure.in and Makefiles
Over that last few months the configure alterations I've been doing has introduced a slightly altered way of system library linkage. Henriks recent commit to remove one of these on grounds of being "old" has highlighted a need to document this and perhapse bring you all in on making the changes. Why? A: The squid binary is topping 3.5MB in footprint with many of the small tool stopping 500KB each. A small but substantial amount of it is libraries inked but unused. Particularly in the helpers. As I've pointed out before the main vector for this is @xtra_l...@. Though component BLAH_LIBS lists are also doing it to a lesser degree. To get around that the new style has been to do: configure.in: AC_CHECK_LIB(xx, foo, [XXLIB="-lxx"]) ... AC_SUBST(XXLIB) */Makefile.am: foo_LDADD= @XXLIB@ With some of the libraries being bunched up when there is a strong link between, ie "-lresolv -lnsl" in @RESOLVLIB@ Does anyone disagree? Does anyone have other examples of libraries which _need_ to include other libraries like -lresolv/-lnsl do for Solaris? I'm not terribly fussed with Henriks change because the DISK IO stuff is heavily interlinked. It's "only" an extra build dependency for every test run. But it grates against my ideologies to see the AIO specific API testers needing to link against the pthreads libraries and vice-versa. Amos
Re: Issue compiling last 3.1 squid in 64-bit platform
Should be fixed in trunk now I hope.. Can you try applying the patch from http://www.squid-cache.org/Versions/v3/HEAD/changesets/squid-3-10105.patch ontop of the tree you downloaded before: note: you need to run bootstrap.sh after patching. tis 2009-11-10 klockan 23:43 +0100 skrev Henrik Nordstrom: > Found the culpit now.. > > configure.in: > > AC_CHECK_LIB(pthread, > main,[DISK_LIBS="$DISK_LIBS -lpthread"], > > > src/Makefile.am: > > squid_DEPENDENCIES = ... > @DISK_LIBS@ \ > > > No idea why that passes without error on my F11 box when other such > errors do not.. > > Regards > Henrik
Re: Issue compiling last 3.1 squid in 64-bit platform
Found the culpit now.. configure.in: AC_CHECK_LIB(pthread, main,[DISK_LIBS="$DISK_LIBS -lpthread"], src/Makefile.am: squid_DEPENDENCIES = ... @DISK_LIBS@ \ No idea why that passes without error on my F11 box when other such errors do not.. Regards Henrik
Re: /bzr/squid3/trunk/ r10096: Bug 2778: fix linking issues using SunCC
ons 2009-11-11 klockan 10:38 +1300 skrev Amos Jeffries: > Worth a query to squid-users. Any OS which is so old it does not support > the auto-tools and libraries we now need is a candidate. I'm thinking > NextStep may be one more. > Though I'm inclined to keep as much support as possible until we have > solid evidence the OS is not able to ever be build Squid. There probably is one or two that may try running Squid on something that once upon a time was Solaris 1.x (known as SunOS 4.x before the name switch to Solaris for everything). But in general terms that OS is pretty much distinct these days. Been declared end-of-life for more than a decade now, with last release in 1994. autotools has never been part of SunOS for that matter, always an addon. And someone patient enough can get up to date autotools + gcc + whatever ontop of SunOS 4.x and build Squid. Question is will anyone really do that? Regards Henrik
Re: Issue compiling last 3.1 squid in 64-bit platform
tis 2009-11-10 klockan 10:28 -0200 skrev rena...@flash.net.br: > make[3]: *** No rule to make target `-lpthread', needed by `all-am'. Stop. > Is your Fedora 11 64-bit? I will install Ubuntu-64 and try to compile it > in the same server. As soon as I have the results I'll post back to you! It is 64-bit. But the problem seem to be dependent on something else. We saw similar problems with trunk some time ago where it failed on my machine but worked on all the machines in the build farm.. can you do grep -- -lpthread src/Makefile Regards Henrik
Re: /bzr/squid3/trunk/ r10095: Fixed linking convention mismatch in Asn ACL
On Tue, 10 Nov 2009 16:46:37 +0100, Kinkie wrote: > On Sat, Nov 7, 2009 at 2:28 AM, Amos Jeffries wrote: >> Francesco Chemolli wrote: >>> >>> >>> revno: 10095 >>> committer: Francesco Chemolli >>> branch nick: trunk >>> timestamp: Fri 2009-11-06 17:12:48 +0100 >>> message: >>> Fixed linking convention mismatch in Asn ACL >>> modified: >>> src/acl/Asn.cc >>> >> >> This is what SQUIDCEXTERN is for. >> ... working towards not needing it as all code converges on C++ builds. > > I can confirm that SQUIDCEXTERN is not working here: the referred-to > function are static, and they need C linkage as they are defined in a > .cc file, but passed as pointers to the radix tree c library. > > Solutions I can see are: > - leaving the extern "C" definition block as is (possbly remove the > #ifdefs, as that file will always be compiled with c++) > - un-static-ify the functions and let them pollute the namespace > - convert the radix-tree library to c++ so no more C linkage will be > needed. > > Opinions? With the move to convenience libraries we have been taking the approach of removing static for things which are in any of the library API. If it does not need to be visible outside the convenience library then its defined internal to the .cc instead and the static maybe kept. Converting the radix code to C++ matches the end-goal of fully C++ code. If you want to take it on go ahead. It is a larger change though and outside the scope of simply fixing build issues. Tumbling down to a second side project of implementing inside configure 'benchmark' micro- unit tests that compare performance and size of several implementations (STL, Boost, Squid custom, other) and makes Squid build with the a) fastest, or b) smallest footprint. This is a major side project though. Amos
Re: /bzr/squid3/trunk/ r10096: Bug 2778: fix linking issues using SunCC
On Tue, 10 Nov 2009 15:47:22 +0100, Kinkie wrote: > On Sat, Nov 7, 2009 at 2:27 AM, Amos Jeffries wrote: >> Francesco Chemolli wrote: >>> >>> >>> revno: 10096 >>> committer: Francesco Chemolli >>> 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. > > Done in revno 10104. > as an aside, does it really matter to support SunOS nowadays? The last > release dates back to 1994, I'd be surprised if ANY kind of surviving > hardware would still support it (but un-supporting the platform is a > different project). Worth a query to squid-users. Any OS which is so old it does not support the auto-tools and libraries we now need is a candidate. I'm thinking NextStep may be one more. Though I'm inclined to keep as much support as possible until we have solid evidence the OS is not able to ever be build Squid. Amos
Re: Issue compiling last 3.1 squid in 64-bit platform
Just tried in Ubuntu 9.10 64-bit and it worked. I think it's something specific to Slackware 13.0 64BIT... Can I help, anyway? Thanks! > Sorry for the "Worked like a charm!" line in my email. It was a mistake. I > was writing the email while the software was compiling and I thought it > worked. When I saw it didn't, I forgot to erase the first line. Blame on > me! > > Sorry! > >> Worked like a charm! >> >> I tried to compile it using no options in configure, but I still get the >> same error in Slackware-64: >> >> 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-BZR/src' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory `/home/sources/squid-3.1.0.14-BZR/src' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory `/home/sources/squid-3.1.0.14-BZR/src' >> make: *** [all-recursive] Error 1 >> >> >> Is your Fedora 11 64-bit? I will install Ubuntu-64 and try to compile it >> in the same server. As soon as I have the results I'll post back to you! >> >> Thanks again! >> >> >> >> No problems at all this time! >> >>> can you try ftp://ftp.squid-cache.se/private/squid-3.1.0.14-BZR.tar.bz2 >>> (snapshot of current sources in bzr) >>> >>> this is fixed so that it builds for me on Fedora 11. >>> >>> >>> tis 2009-11-10 klockan 09:14 -0200 skrev rena...@flash.net.br: If you need me to do any type of specific test or use any compile options, please let me know and I would be glad to help! Thanks again for your effort! > tis 2009-11-10 klockan 23:41 +1300 skrev Amos Jeffries: > >> Yet I ported those fixes down and he still reports it in the snapshot >> built afterwards. :( > > I think something went wrong in that port, the build farm also failed.. > > was a number of iterations in trunk before it worked right. > > Regards > Henrik > > >>> >>> >> >> >> > > >
Re: /bzr/squid3/trunk/ r10095: Fixed linking convention mismatch in Asn ACL
On Sat, Nov 7, 2009 at 2:28 AM, Amos Jeffries wrote: > Francesco Chemolli wrote: >> >> >> revno: 10095 >> committer: Francesco Chemolli >> branch nick: trunk >> timestamp: Fri 2009-11-06 17:12:48 +0100 >> message: >> Fixed linking convention mismatch in Asn ACL >> modified: >> src/acl/Asn.cc >> > > This is what SQUIDCEXTERN is for. > ... working towards not needing it as all code converges on C++ builds. I can confirm that SQUIDCEXTERN is not working here: the referred-to function are static, and they need C linkage as they are defined in a .cc file, but passed as pointers to the radix tree c library. Solutions I can see are: - leaving the extern "C" definition block as is (possbly remove the #ifdefs, as that file will always be compiled with c++) - un-static-ify the functions and let them pollute the namespace - convert the radix-tree library to c++ so no more C linkage will be needed. Opinions? Thanks -- /kinkie
Re: /bzr/squid3/trunk/ r10096: Bug 2778: fix linking issues using SunCC
On Sat, Nov 7, 2009 at 2:27 AM, Amos Jeffries wrote: > Francesco Chemolli wrote: >> >> >> revno: 10096 >> committer: Francesco Chemolli >> 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. Done in revno 10104. as an aside, does it really matter to support SunOS nowadays? The last release dates back to 1994, I'd be surprised if ANY kind of surviving hardware would still support it (but un-supporting the platform is a different project). -- /kinkie
Re: Issue compiling last 3.1 squid in 64-bit platform
Sorry for the "Worked like a charm!" line in my email. It was a mistake. I was writing the email while the software was compiling and I thought it worked. When I saw it didn't, I forgot to erase the first line. Blame on me! Sorry! > Worked like a charm! > > I tried to compile it using no options in configure, but I still get the > same error in Slackware-64: > > 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-BZR/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/sources/squid-3.1.0.14-BZR/src' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/sources/squid-3.1.0.14-BZR/src' > make: *** [all-recursive] Error 1 > > > Is your Fedora 11 64-bit? I will install Ubuntu-64 and try to compile it > in the same server. As soon as I have the results I'll post back to you! > > Thanks again! > > > > No problems at all this time! > >> can you try ftp://ftp.squid-cache.se/private/squid-3.1.0.14-BZR.tar.bz2 >> (snapshot of current sources in bzr) >> >> this is fixed so that it builds for me on Fedora 11. >> >> >> tis 2009-11-10 klockan 09:14 -0200 skrev rena...@flash.net.br: >>> If you need me to do any type of specific test or use any compile >>> options, >>> please let me know and I would be glad to help! >>> >>> Thanks again for your effort! >>> >>> > tis 2009-11-10 klockan 23:41 +1300 skrev Amos Jeffries: >>> > >>> >> Yet I ported those fixes down and he still reports it in the >>> snapshot >>> >> built afterwards. :( >>> > >>> > I think something went wrong in that port, the build farm also >>> failed.. >>> > >>> > was a number of iterations in trunk before it worked right. >>> > >>> > Regards >>> > Henrik >>> > >>> > >>> >> >> > > >
Re: Issue compiling last 3.1 squid in 64-bit platform
Worked like a charm! I tried to compile it using no options in configure, but I still get the same error in Slackware-64: 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-BZR/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sources/squid-3.1.0.14-BZR/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sources/squid-3.1.0.14-BZR/src' make: *** [all-recursive] Error 1 Is your Fedora 11 64-bit? I will install Ubuntu-64 and try to compile it in the same server. As soon as I have the results I'll post back to you! Thanks again! No problems at all this time! > can you try ftp://ftp.squid-cache.se/private/squid-3.1.0.14-BZR.tar.bz2 > (snapshot of current sources in bzr) > > this is fixed so that it builds for me on Fedora 11. > > > tis 2009-11-10 klockan 09:14 -0200 skrev rena...@flash.net.br: >> If you need me to do any type of specific test or use any compile >> options, >> please let me know and I would be glad to help! >> >> Thanks again for your effort! >> >> > tis 2009-11-10 klockan 23:41 +1300 skrev Amos Jeffries: >> > >> >> Yet I ported those fixes down and he still reports it in the snapshot >> >> built afterwards. :( >> > >> > I think something went wrong in that port, the build farm also >> failed.. >> > >> > was a number of iterations in trunk before it worked right. >> > >> > Regards >> > Henrik >> > >> > >> > >
Re: Issue compiling last 3.1 squid in 64-bit platform
can you try ftp://ftp.squid-cache.se/private/squid-3.1.0.14-BZR.tar.bz2 (snapshot of current sources in bzr) this is fixed so that it builds for me on Fedora 11. tis 2009-11-10 klockan 09:14 -0200 skrev rena...@flash.net.br: > If you need me to do any type of specific test or use any compile options, > please let me know and I would be glad to help! > > Thanks again for your effort! > > > tis 2009-11-10 klockan 23:41 +1300 skrev Amos Jeffries: > > > >> Yet I ported those fixes down and he still reports it in the snapshot > >> built afterwards. :( > > > > I think something went wrong in that port, the build farm also failed.. > > > > was a number of iterations in trunk before it worked right. > > > > Regards > > Henrik > > > > >
Introducing Myself
Greetings, My name is Renato, I'm from Brazil and I work as a network and server administrator consultant full time. We have several squid servers and now I'm very glad to be able to test the DEV brand of this incredible software. Actually I like the tproxy new feature integrated to the 3.1 brand very much and I would like to share information about it... Thank you!
Re: Issue compiling last 3.1 squid in 64-bit platform
If you need me to do any type of specific test or use any compile options, please let me know and I would be glad to help! Thanks again for your effort! > tis 2009-11-10 klockan 23:41 +1300 skrev Amos Jeffries: > >> Yet I ported those fixes down and he still reports it in the snapshot >> built afterwards. :( > > I think something went wrong in that port, the build farm also failed.. > > was a number of iterations in trunk before it worked right. > > Regards > Henrik > >
Re: Issue compiling last 3.1 squid in 64-bit platform
tis 2009-11-10 klockan 23:41 +1300 skrev Amos Jeffries: > Yet I ported those fixes down and he still reports it in the snapshot > built afterwards. :( I think something went wrong in that port, the build farm also failed.. was a number of iterations in trunk before it worked right. Regards Henrik
Re: Issue compiling last 3.1 squid in 64-bit platform
Henrik Nordstrom wrote: 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 Thats what I thought Henrik. Yet I ported those fixes down and he still reports it in the snapshot built afterwards. :( 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
As this is a test server, I did a fresh install of the Slackware-64 and tried to install the newly version of the 3.1 snapshot without any options passed to the configure. It gave me the same compile error (lpthread). Thanks! > 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 >
