Bug#622092: cyrus-imapd-2.2: fix for build with multiarch

[Ondřej Surý]

Or to put it in another way. I am convinced that >= 2.2.13p1-1 package
has already the needed fix, since this snippet:

        AC_CHECK_LIB(com_err, com_err, [
                # com_err is already in library path
                # guess we're okay
                # can use system com_err
                with_com_err=""
                AC_CHECK_HEADER(et/com_err.h,
                  [AC_DEFINE(HAVE_ET_COM_ERR_H,[],[We need et/com_err.h])],
                  [AC_CHECK_HEADER(com_err.h,[],[AC_ERROR([cannot
locate com_err.h])])])
                AC_PATH_PROG(COMPILE_ET, compile_et, [no compile et])
        ], [

should work if the configure script can find libcom_err.so,
et/com_err.h and compile_et binary.

Ondrej

On Sun, Apr 10, 2011 at 21:30, Ondřej Surý <ondrej at sury.org> wrote:
> Hi Steve,
>
> you didn't check enough :). The triple check was needed. The current
> cyrus-imapd debian package (>= 2.2.13p1-1 and >= 2.4.6-3) runs
> configure with --with-com_err="" which is different from just using
> --with-com_err.
>
> Using --with-com_err sets the value to 'yes' which makes cyrus-imapd
> configure script to do special handling and using local com_err
> library, which is hardly what you really want.
>
> This configure.in snippet is responsible:
>
> case "$with_com_err" in
>  # built-in et
>  yes) # use the com_err we're gonna build
>          COM_ERR_LIBS="../com_err/et/libcom_err.a"
>          COMPILE_ET="../com_err/et/compile_et"
>          COM_ERR_LDFLAGS=""
>          COM_ERR_CPPFLAGS="-I\${top_srcdir}/com_err/et"
>          PRE_SUBDIRS="com_err/et ${PRE_SUBDIRS}"
>          EXTRA_OUTPUT="${EXTRA_OUTPUT} com_err/et/Makefile"
>          ;;
>  "")   # no problem, we already have it in the paths
>        # we do nothing to pick it up
>        COM_ERR_LIBS="-lcom_err" # hope it's not shared
>        # we already set COMPILE_ET, or we didn't get here
>        COM_ERR_LDFLAGS=""
>        COM_ERR_CPPFLAGS=""
>      ;;
>  *) # use whatever they told us, or whatever we found
>     COMPILE_ET="${with_com_err}/bin/compile_et"
>     COM_ERR_LIBS="${with_com_err}/lib/libcom_err.a"
>     COM_ERR_CPPFLAGS="-I${with_com_err}/include"
>     # Ever get the feeling people hide this stuff on purpose?
>     if test -d "${with_com_err}/include/et" ; then
>       COM_ERR_CPPFLAGS="-I${with_com_err}/include/et"
>     fi
> dnl     CMU_ADD_LIBPATH_TO(${with_com_err}/lib, COM_ERR_LDFLAGS)
>     COMPILE_ET="${with_com_err}/bin/compile_et"
> esac
>
>
> Ondrej
>
> On Sun, Apr 10, 2011 at 21:11, Steve Langasek
> <steve.langasek at canonical.com> wrote:
>> On Sun, Apr 10, 2011 at 09:49:05AM -0300, Henrique de Moraes Holschuh wrote:
>>> On Sun, 10 Apr 2011, Steve Langasek wrote:
>>> > multiarch.  The attached patch has been applied in Ubuntu for this issue,
>>> > correcting this call to use --with-com_err with no argument to get the
>>> > default search path.
>>
>>> Has this been triple-checked to do the right thing?
>>
>> No, only double-checked.  I had reviewed the source of configure.in which
>> was how I spotted the difference between --with-com_err and
>> --with-com_err=/usr; but it turns out that what's actually needed is
>> --with-com_err= rather than --with-com_err since --with-com_err is
>> --equivalent to --with-com_err=yes.  Thanks for making me take a
>> third look at this.
>>
>>> I used to have to employ extremely hard measures (aka rm -fr et/ in
>>> debian/rules clean) to convince the Cyrus build to not do anything
>>> extremely hazardous, such as using pieces of system com-err and pieces of
>>> cyrus com-err.  I *really* would not trust configure to not do something
>>> idiotic without directly checking the object files and poisoning the local
>>> copies of com-err to fail any build that touches them, so as to make sure
>>> everything is doing what it is supposed to...
>>
>> After switching to --with-com_err=, I've confirmed that there are no longer
>> any mentions of libcom_err.a in the build log.  So I'm personally convinced
>> that this is sufficient, but of course if you would prefer a
>> fix-upstream-harder solution you are welcome to it.
>>
>> Cheers,
>> --
>> Steve Langasek                   Give me a lever long enough and a Free OS
>> Debian Developer                   to set it on, and I can move the world.
>> Ubuntu Developer                                    http://www.debian.org/
>> slangasek at ubuntu.com                                     vorlon at debian.org
>>
>> _______________________________________________
>> Pkg-Cyrus-imapd-Debian-devel mailing list
>> Pkg-Cyrus-imapd-Debian-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-imapd-debian-devel
>>
>
>
>
> --
> Ondřej Surý <ondrej at sury.org>
>



-- 
Ondřej Surý <ondrej at sury.org>