On Wed, Nov 21, 2012 at 10:06:34PM -0800, Murray S. Kucherawy wrote:
> I've pushed some revised code to the 'develop' branch that I think will
> work, but I haven't tried it on Linux systems yet. Feel free to give it a
> go if you have time in the next few days, as I likely won't until the
> weekend.
1/ fresh install of opendkim-2.7.2 with no libstrl.so or strl.h present
on the system => works
2/ fresh install of opendkim-2.7.2 with libstrl.so and strl.h provided
by an external library => works
3/ upgrading from opendkim-2.7.1 => configure script sees libstrl.so and
strl.h (provided by opendkim-2.7.1) and does not build its own
libstrl. When opendkim-2.7.2 is installed on the system,
package manager removes libstrl from the system because it is
part of the opendkim-2.7.1 package. Result: opendkim-2.7.2
linking against a non-existing libstrl.so.
Basically, configure script does not differentiate between
options 2 and 3. I can work around it in the package manager
- by not removing libstrl.so of opendkim-2.7.1 - but it is not
a nice solution.
Also, if you ever change the code in libstrl, it won't get build
during upgrades from previous versions of opendkim.
Nitpick: Configure output does not look nice:
checking for strl.h in /usr/local/include/strl... checking for strl.h in
/usr/include/strl... checking strl.h usability... yes
You might want to consider the attached patch for a cosmetic change in
configure output.
--
Eray
Received on Thu Nov 22 2012 - 14:09:20 PST