mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: musl@lists.openwall.com
Subject: Re: the definition of (u)int64_t with gcc -m32 in stdint.h
Date: Thu, 21 Aug 2014 08:25:40 -0700	[thread overview]
Message-ID: <CAMKF1srHx6v8Ns-DhS3zMzP7neaFqA0JMhn7QVoP-wMbP-r9xw@mail.gmail.com> (raw)
In-Reply-To: <20140821171511.06869699@ncopa-desktop.alpinelinux.org>

On Thu, Aug 21, 2014 at 8:15 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> Hi,
>
> After migrating from uclibc to musl libc the Xen hvmloader broke. This
> is a 32bit bootloader that is built on 64 bit hosts with gcc -m32.
>
> Someone told me breakage had to do with datastructs beeing 64 bit even
> with -m32. I also saw someone comment that it shoudl been built with
> -nostdinc.
>
> I tried this and it revealed that yes, indeed, the hvmloader does use
> the host system stdint.h and stdarg.h.
>
> Curious on why it works on uclibc but not with musl i found out that
> uclibc/glibc sets (u)int64_t depening on __WORDSIZE:
>
> # if __WORDSIZE == 64
> typedef long int                int64_t;
> # else
> __extension__
> typedef long long int           int64_t;
> # endif
>
>
> and wordsize is set in /usr/include/bits/wordsize.h:
> /* Determine the wordsize from the preprocessor defines.  */
>
> #if defined __x86_64__
> # define __WORDSIZE     64
> /* This makes /var/run/utmp compatible with 32-bit environment: */
> # define __WORDSIZE_COMPAT32    1
> #else
> # define __WORDSIZE     32
> #endif
>
>
> the __x86_64__ define is set by gcc and is set differently when -m32 is
> specified or not.
>
> A testcase. On uclibc 64 bit host:
> dev-2-7-x86_64:~$ echo '#include <stdint.h>' | gcc -m32 -E - | grep int64
> typedef long long int int64_t;
> typedef unsigned long long int uint64_t;
>
>
> Same on musl libc 64 bit host:
> $ echo '#include <stdint.h>' | gcc -m32 -E - | grep int64
> typedef long int64_t;
> typedef unsigned long uint64_t;
> typedef int64_t int_fast64_t;
> typedef int64_t int_least64_t;
> typedef uint64_t uint_fast64_t;
> typedef uint64_t uint_least64_t;
>
>
> so on musl it is 'long' but on uclibc its 'long long int'.
>
> That explains why it works on uclibc but not on musl.
>
> Now, what is the proper way to fix it? Preferible without replacing
> all (u)int*_t all places in xen code. I doubt upstream will accept that.
>

Do we support multilib with musl yes ?

> -nc


  reply	other threads:[~2014-08-21 15:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21 15:15 Natanael Copa
2014-08-21 15:25 ` Khem Raj [this message]
2014-08-21 16:47   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMKF1srHx6v8Ns-DhS3zMzP7neaFqA0JMhn7QVoP-wMbP-r9xw@mail.gmail.com \
    --to=raj.khem@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).