Re: [autoconf] 32/64-bit systems

[mpsuzuki]

On Mon, 14 Jul 2008 12:24:31 -0400
"Ben Taylor" <address@hidden> wrote:

>On Mon, Jul 14, 2008 at 11:46 AM,  <address@hidden> wrote:
>> Hi,
>>
>> On Mon, 14 Jul 2008 08:32:44 -0400
>> "Ben Taylor" <address@hidden> wrote:
>>>so i have something like prefix/lib and prefix/lib/sparcv9 for sparc
>>>and prefix/lib and prefix/lib/amd64 for x64.
>>
>> This naming convention is standard among Solaris developers?
>
>That's the standard Sun uses for their 64-bit libraries on Sparc
>and X86-64.  Normal 32-bit follows ${prefix}/lib

Thank you for info. When I pass the option "-L/xxx/lib" only,
the commercial C compilers for Solaris will search /xxx/lib only?
Or, it automatically searches /xxx/lib, /xxx/lib/sparcv4, and
/xxx/lib/amd64, regardless with the target architechture?
Or, other options to specify the architecture (something like
"-march=sparcv4" of gcc) silently modifies the pathname from
/xxx/lib to /xxx/lib/sparcv4?

>> Hmm, autoconf's AC_CHECK_LIB([NAME], [FUNC], [...]) provides
>> the feature what you want, I guess. It would not search the
>> pathname of libNAME, but it would execute
>>        ${CC} ${CFLAGS} ${LDFLAGS} conftest.c -lNAME
>> conftest.c refers FUNC. Do you think you found the bug of
>> autoconf?
>
>I think so.  Mainly because it's returning the full path of the
>32-bit library on a 64-bit system.  If it was returning -liconv
>(in this instance) I'm pretty sure the test would pass.

I sympathize your inconvenience, but I think, it's misunderstanding.

Please be careful, autoconf is primarily a tool set (and very
fundamental macro set) to generate configure script from
configure.ac. If an author writes a program that works on some
machines and does not work on others, it does not mean that
the C compiler has a bug. The first point we have to check is the 
program has a bug /or not. In our case, we have to check if the
configure.ac in gnupg.ac has a "bug" or not.

Let's check gnupg-x.y.z/configure.ac:

        #
        # Checking for iconv
        #
        AM_ICONV

Oh, what kind of things AM_ICONV do? Let's check gnupg-x.y.z/m4/
iconv.m4, written by Bruno Haible, the author of GNU libiconv.

        AC_DEFUN([AM_ICONV_LINKFLAGS_BODY],
        [
          dnl Prerequisites of AC_LIB_LINKFLAGS_BODY.
          AC_REQUIRE([AC_LIB_PREPARE_PREFIX])
          AC_REQUIRE([AC_LIB_RPATH])

          dnl Search for libiconv and define LIBICONV, LTLIBICONV and INCICONV
          dnl accordingly.
          AC_LIB_LINKFLAGS_BODY([iconv])
        ])

        ...

Hmm, what is AC_LIB_LINKFLAGS_BODY? It looks like the root why
configure of gnupg tries to find the exact pathname, instead
of determine appropriate CFLAGS & LDFLAGS. I can find this macro
in lib-link.m4, written by Bruno Haible, the maintainer of GNU
gettext.

        dnl AC_LIB_LINKFLAGS_BODY(name [, dependencies]) searches for libname 
and
        dnl the libraries corresponding to explicit and implicit dependencies.
        dnl Sets the LIB${NAME}, LTLIB${NAME} and INC${NAME} variables.
        dnl Also, sets the LIB${NAME}_PREFIX variable to nonempty if libname 
was found
i       dnl in ${LIB${NAME}_PREFIX}/$acl_libdirstem.
        AC_DEFUN([AC_LIB_LINKFLAGS_BODY],
        [

        ...

Anyway, both of iconv.m4 & link-lib.m4 are out of autoconf, the
developers of autoconf cannot fix the "bug" (or unwanted behaviour).

As described in the comment, AC_LIB_LINKFLAGS_BODY() is a macro
to lookup the exact library pathname and GNU-libtool's ".la" file,
thus, if the author used AC_LIB_LINKFLAGS_BODY, he decided to
ignore the possibility that the libraries are stored in per-
architechture directories, like recent Solaris. Changing the
AC_LIB_LINKFLAGS_BODY() is insufficient, because other parts
in iconv.m4 tries to use LIBICONV, LTLIBICONV and INCICONV.
Fundamental fix of iconv.m4 or gnupg-x.y.z/configure.ac is needed,
I think.

When I search AC_LIB_LINKFLAGS_BODY() in google, I found several
complaints against its insufficient support for the system with
multiple libraries, for example,

        http://www.mail-archive.com/address@hidden/msg09473.html

I think, the "bug" you found should be discussed and solved by
gnupg maintainers (they can clarify what kind of informations
should be detected) and Bruno Haible (he can clarify if it's
possible by using iconv.m4/lib-link.m4 or not).

Personally, considering the situation that a common header files
are stored in /XXX/include and the architecture-specific libraries
are stored in multiple directories /XXX/lib/sparcv9, /XXX/lib/amd64
etc, the improvement of GNU libtool (and pkg-config?) would be
expected, but yet I don't have concrete idea.

Regards,
mpsuzuki