]> git.ipfire.org Git - thirdparty/squid.git/commit
Fixed the problem with Squid executable missing code to process ACLs.
authorAlex Rousskov <rousskov@measurement-factory.com>
Tue, 17 Mar 2009 02:04:14 +0000 (20:04 -0600)
committerAlex Rousskov <rousskov@measurement-factory.com>
Tue, 17 Mar 2009 02:04:14 +0000 (20:04 -0600)
commit2d46f5799aaa9fe143cda648ba4e7ec2d18def1b
tree48f34164823c6dabbec51cad4f40e7f8d6ffbde3
parent945c70bbf74f8993c2f2feee4bd6464c4a5f820f
Fixed the problem with Squid executable missing code to process ACLs.
The solution will probably be replaced by a better one eventually.

Background:

Squid uses a "registry pattern" to register parsing and matching code specific
to most ACL types. The registration happens in acl/libacls convenience
library. The rest of Squid does not know about specific ACL types; it only has
access to a registry of pointers to what looks like generic ACL objects.  When
Squid executable is linked, most object files containing specific ACL types
are dropped (i.e., ignored) by the linker because they do not satisfy any
unresolved symbols and, hence, deemed unnecessary.

ACL object files were not missing when Squid executable was built using
explicit ACL object files names because the linker treats those differently
than object files in a convenience library -- it includes them whole.

Attempts to find a fix:

My attempts to link with a static convenience library (libtool's -static
option when defining the library) were not successful: the end result is the
same. The static and regular convenience libraries appear to be different, but
the linker, apparently, troughs out "unnecessary" symbols from both.

My attempts to pass -whole-archive to the linker were not successful: libtool
would reorder the arguments when calling the actual linker, resulting in the
wrong parameter order. I did protect -Wl,-whole-archive and friends with
AC_SUBST() and tried a few different versions of that protection, but was not
successful. It is possible that I just did not find the right trick to make it
work. However, -whole-archive is not portable so it would not be an ideal
solution anyway.

The fix:

I have moved registration code from src/acl/* sources into a src/AclRegs.cc
file, making the latter the source file for Squid executable. With this
change, Squid knows about specific ACL types (because they are needed by the
registration code) and the corresponding ACL classes get linked.

A similar solution is currently used for DiskIO modules, except there the
"pull everything in" source file (DiskIO/DiskIOModules_gen.cc) is generated
and called explicitly.  We may end up generating AclRegs.cc as well, but there
does not seem to be a particular advantage of adding that level of complexity.

Future:

A few options are available:

a) Find flaws in the above attempts to convince libtool to do the right thing
and fix the problem using libtool parameters alone.

b) Wait for libtool to support the kind of convenience library that we need
(the one that does -whole-archive when building an executable).

c) Add some kind of Acl::ModuleInit() global that Squid would call to register
known ACL types. AclRegs.cc code can be moved to acl/* sources then.
29 files changed:
src/AclRegs.cc [new file with mode: 0644]
src/Makefile.am
src/acl/Arp.cc
src/acl/Browser.cc
src/acl/Certificate.cc
src/acl/DestinationDomain.cc
src/acl/DestinationIp.cc
src/acl/ExtUser.cc
src/acl/HttpRepHeader.cc
src/acl/HttpReqHeader.cc
src/acl/HttpStatus.cc
src/acl/Ident.cc
src/acl/MaxConnection.cc
src/acl/Method.cc
src/acl/MyIp.cc
src/acl/MyPort.cc
src/acl/MyPortName.cc
src/acl/PeerName.cc
src/acl/Protocol.cc
src/acl/Referer.cc
src/acl/ReplyMimeType.cc
src/acl/RequestMimeType.cc
src/acl/SourceDomain.cc
src/acl/SourceIp.cc
src/acl/SslError.cc
src/acl/Time.cc
src/acl/Url.cc
src/acl/UrlPath.cc
src/acl/UrlPort.cc