[squid-dev] libltdl in squid

[Amos Jeffries]

On 13/06/2015 1:54 a.m., Eray Aslan wrote:
> Is there any particular reason we are shipping and building libltdl in
> squid tarballs?  Problem I am facing is when I run autoreconf,
> libtoolize blindly copies over am__api_version -which has the automake
> version libtool was compiled with and not the version currently running
> on the system- to aclocal.m4 which later errors out.
> 
> While libtoolize behaviour is certainly not ideal, why is squid not
> using the system libltdl?  That seems to be the correct course of
> action.  Is there a downside to getting rid of libltdl that I am
> missing?
> 
> Gory details at:
> https://bugs.gentoo.org/show_bug.cgi?id=536420
> 
> Thank you.
> 

Hi Eray,
 Squid should be using the system libltdl.

IIUIC, the ./libltdl/ bits are in two parts:
- the headers and bits for building an lib*.a to link with. Which are
used as if libltdl was installed in the system includes/ directory.
Run-time it dynamicaly loads the system libltdl.

- also a sub-dir with bits to build a static libltdl. This requires the
--use-included-ltdl option to build and overrides the above run-time load.


I am wondering how you can have libtoolize run and not have the contents
of the libltdl directory entirely replaced to be compatible with the
current OS version. Because, thats exactly what we do to generate it in
the first place.
 Is there possibly multiple libltdl installed on the build system and
libtoolize embedding info from the non-dominant system libltdl version
into Squid?
 There was a hint in the bug that automake was embedding code files
indicating bogus version details.


NP: It is bundled for the old OS or ones that dont supply any
libtool/ltdl compatible with the autoconf version we generate Squid with.


Amos