Ralf Wildenhues wrote:
Hello Amos,
* Amos Jeffries wrote on Mon, May 04, 2009 at 03:16:50AM CEST:
Yes it is Squid-3.
The official snapshot bundle can be found at:
http://www.squid-cache.org/Versions/v3/HEAD/
The bundle is generated on another OS with older autoconf version that
does not have this issue. The problem appears when this is bootstrapped to
the newer autotools chain.
I can confirm the
config.status: executing libtool commands
/bin/rm: cannot remove `libtoolT': No such file or directory
issue. It is due to both the Libtool macros and the configure.in
defining $RM, and configure.in uses
AC_PATH_PROG(RM, rm, $FALSE)
whereas the Libtool macros expect "rm -f". One fix could be to
AC_PATH_PROG(RM, rm, $FALSE)
RM="$RM -f"
I agree that Libtool should probably document this RM usage.
Excellent. Thank you.
AFAICT there is no harm in doing "rm -f -f" so libtool doing "$RM -f" as
I said initially will be no loss for libtool to perform and much to be
gained by all the libtool projects such as ours that do not need the -f
and will otherwise have to add and maintain this hack individually.
I can also forsee projects which will be unable to add this hack. We
ourselves are moving towards a level of active testing where a rm
failure to remove something can be sign of major code errors occuring
elsewhere where it was supposedly created. ie the ClientInfo.h dist
error you found below. Adding -f globally makes that testing useless.
We are lucky the few things we might have already converted to depend on
rm results are not yet done. They will now have to be shelved.
Just my 2c.
I'll add the hack for now and await further improvements.
Thank you again.
The linkage problem is then displayed by:
mkdir test && cd test && ../configure --silent && make check
What problem is this? Can you post the libtool --mode=link command that
fails, plus all of its output?
I don't get as far as running "make check": "make all" already fails on
make[3]: Entering directory `/tmp/squid/squid-3.HEAD-20090507/build/src'
depbase=`echo mem.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../../lib -I../src -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -MT
mem.o -MD -MP -MF $depbase.Tpo -c -o mem.o ../../src/mem.cc &&\
mv -f $depbase.Tpo $depbase.Po
../../src/mem.cc:38:24: error: ClientInfo.h: No such file or directory
../../src/mem.cc: In static member function 'static void Mem::Init()':
../../src/mem.cc:424: error: 'ClientInfo' was not declared in this scope
make[3]: *** [mem.o] Error 1
but that's presumably because I don't have all build-prereqs installed
(how would I get them, on a mostly-stable Debian)?
Ah no sorry that was our fault. We had a small fubar of the dist files.
Now fixed and should be in the next snapshot.
Meanwhile the requested info is:
bin/bash ../libtool --tag=CXX --mode=link g++ -Werror -Wall
-Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -g -o squid
-export-dynamic -dlopen force AclRegs.o AuthReg.o access_log.o asn.o
AsyncEngine.o cache_cf.o ProtoPort.o CacheDigest.o cache_manager.o
carp.o cbdata.o ChunkedCodingParser.o client_db.o client_side.o
client_side_reply.o client_side_request.o BodyPipe.o clientStream.o
CompletionDispatcher.o comm_select.o comm_select_win32.o comm_poll.o
comm_epoll.o comm_kqueue.o ConfigOption.o ConfigParser.o debug.o disk.o
DiskIO/DiskIOModule.o DiskIO/ReadRequest.o DiskIO/WriteRequest.o dlink.o
dns_internal.o errorpage.o ETag.o event.o EventLoop.o external_acl.o
ExternalACLEntry.o fd.o fde.o filemap.o forward.o fqdncache.o ftp.o
gopher.o helper.o htcp.o http.o HttpStatusLine.o HttpHdrCc.o
HttpHdrRange.o HttpHdrSc.o HttpHdrScTarget.o HttpHdrContRange.o
HttpHeader.o HttpHeaderTools.o HttpBody.o HttpMsg.o HttpReply.o
HttpRequest.o HttpRequestMethod.o icp_v2.o icp_v3.o ident.o int.o
internal.o ipc.o ipcache.o list.o logfile.o main.o mem.o mem_node.o
MemBuf.o MemObject.o mime.o multicast.o neighbors.o Packer.o Parsing.o
pconn.o peer_digest.o peer_select.o peer_sourcehash.o peer_userhash.o
redirect.o referer.o refresh.o RemovalPolicy.o send-announce.o
snmp_core.o snmp_agent.o SquidNew.o stat.o StatHist.o String.o stmem.o
store.o StoreFileSystem.o store_io.o StoreIOState.o store_client.o
store_digest.o store_dir.o store_key_md5.o store_log.o store_rebuild.o
store_swapin.o store_swapmeta.o store_swapout.o StoreMeta.o
StoreMetaMD5.o StoreMetaSTD.o StoreMetaSTDLFS.o StoreMetaUnpacker.o
StoreMetaURL.o StoreMetaVary.o StoreSwapLogData.o Server.o SwapDir.o
time.o tools.o tunnel.o unlinkd.o url.o URLScheme.o urn.o useragent.o
wccp.o wccp2.o whois.o wordlist.o LoadableModule.o LoadableModules.o
DiskIO/DiskIOModules_gen.o repl_modules.o globals.o string_arrays.o
libsquid.la auth/libacls.la acl/libacls.la acl/libstate.la
auth/libauth.la acl/libapi.la base/libbase.la ip/libip.la fs/libfs.la
icmp/libicmp.la icmp/libicmp-core.la -L../lib
DiskIO/Blocking/BlockingDiskIOModule.o repl/liblru.a libBlocking.a
-lcrypt ../snmplib/libsnmp.a -lmiscutil -lm -lresolv -lnsl -ldl
lib/libLtdl/libltdlc.la
libtool: link: cannot find the library `lib/libLtdl/libltdlc.la' or
unhandled argument `lib/libLtdl/libltdlc.la'
Thats the lot of the visible error.
Thats built from src/Makefile so it actually exists at
../lib/libLtdl/libltdlc.la
Amos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
