Re: Misleading configure failure GLIB_SIZEOF_SIZE_T

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 18 Mar 2021 at 12:53, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> I just ran into this failure:
>>
>>     $ ../configure --disable-tools --disable-system --static
>>
>>     ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
>>            You probably need to set PKG_CONFIG_LIBDIR
>>            to point to the right pkg-config files for your
>>            build target
>
> The interesting question here is why the earlier configure check:
>
> write_c_skeleton;
> if compile_object ; then
>   : C compiler works ok
> else
>     error_exit "\"$cc\" either does not exist or does not work"
> fi
> if ! compile_prog ; then
>     error_exit "\"$cc\" cannot build an executable (is your linker broken?)"
> fi
>
> didn't fail. That is deliberately early in configure in an attempt
> to capture this kind of "the compiler can't link anything" case
> before we get into specific feature testing.

I've since installed the libraries...  uninstalling glibc-static for a
quick check...  Yep, dies in the GLIB_SIZEOF_SIZE_T test.  Let's have a
look at my config.log.  To more easily find the check you pointed out, I
stuck "exit 42" right behind it, and get:

    $ ./config.status 
    [Exit 42 ]
    $ echo $?
    42
    $ tail -n 4 config.log 

    funcs: do_compiler do_cc compile_prog main
    lines: 145 183 2017 0
    cc -std=gnu99 -Wall -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64
    $ cat config-temp/qemu-conf.c 
    int main(void) { return 0; }

Run the compiler by hand to confirm:

    $ cc -std=gnu99 -Wall -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64
    $ echo $?
    0

The test program doesn't actually need libc, so not having glibc-static
installed doesn't bother the linker.

If it used something from libc, then I'd expect the issue to merely
shift to the next library.  Remember, the failure I reported attempts to
link with -lgthread-2.0 -pthread -lglib-2.0 -pthread -lpcre -pthread.