mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: K Jelesnianski <kjski@vt.edu>
Cc: musl@lists.openwall.com
Subject: Re: compiling SPECCPU2006 against Musl
Date: Sat, 13 Oct 2018 21:51:06 -0400	[thread overview]
Message-ID: <20181014015106.GH5150@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAH=yU0aQ1BTdN3J5_bVxM3-KO_sb8WKaZsR3wVNvJy-9EohKEA@mail.gmail.com>

On Sat, Oct 13, 2018 at 05:47:50PM -0400, K Jelesnianski wrote:
> Dear mailing list,
> 
> I am curious if anyone has any insight on how to link the SPECCPU2006
> benchmarks against Lusl Libc. Reading FAQ I saw that Musl does *not* have
> C++ support out of the box but can still "hopefully" work in some cases
> against glibstdc++
> I havent found any resources or guides on-line of people doing this.

I would not describe it as "musl does not have C++ support". Rather,
musl is not an implementation of the C++ stdlib (and neither is
glibc), but that just means you use whichever C++ stdlib you want with
it (GCC's libstdc++ or the llvm-associated libc++).

> Anyways I am only focusing on the C implementation SPEC benchmarks and out
> of this subset I was still only able to compile a few. The following do not
> compile against MUSL:
> 400.perlbench
> 403.gcc
> 462.libquantum
> 
> I tried to use both clang 6.0.0 and gcc and got the following error below
> (Dump at end of email). Any thoughts?
> for perlbench - at first was "undefined reference to __isnan" but then
> after adding -I/path/to/musl/install/include I got even more errors. I am
> using the -std=gnu89 flag since this was how SPEC documented its fix for a
> multiple definition error. The other 2 benchmarks show similar errors.

It sounds like something is wrong with your setup for making the
toolchain target musl. Repurposing an existing toolchain that's
pulling in library and include dirs from whatever your existing host
libc is (presumably glibc) is hard to get right. See below:

> Sincerely,
> K Jelesnianski
> 
> Error Dump for perlbench:
> 
> clang -c -o perlio.o -DSPEC_CPU -DNDEBUG -DPERL_CORE   -O2
> -fno-strict-aliasing -g -fPIC -fomit-frame-pointer
> -I/home/c/workspace/research/mardu/bin/include       -DSPEC_CPU_LP64
> -DSPEC_CPU_LINUX_X64 -std=gnu89        perlio.c
> In file included from perlio.c:50:
> In file included from ./perl.h:384:
> In file included from
> /home/c/workspace/research/mardu/bin/include/sys/types.h:70:
> /home/c/workspace/research/mardu/bin/include/endian.h:32:25: warning:
> '&' within '|' [-Wbitwise-op-parentheses]
>         return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
>                        ~ ~~~~~~^~~~~~~
> /home/c/workspace/research/mardu/bin/include/endian.h:32:25: note:
> place parentheses around the '&' expression to silence this warning
>         return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
>                                ^
>                          (            )
> /home/c/workspace/research/mardu/bin/include/endian.h:32:41: warning:
> '&' within '|' [-Wbitwise-op-parentheses]
>         return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
>                                        ~ ~~~~~~^~~~~~~~~
> /home/c/workspace/research/mardu/bin/include/endian.h:32:41: note:
> place parentheses around the '&' expression to silence this warning
>         return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
>                                                ^
>                                          (              )
> /home/c/workspace/research/mardu/bin/include/endian.h:37:23: warning:
> operator '<<' has lower precedence than '+'; '+' will be evaluated
> first [-Wshift-op-parentheses]
>         return __bswap32(__x)+0ULL<<32 | __bswap32(__x>>32);
>                ~~~~~~~~~~~~~~^~~~~~~
> /home/c/workspace/research/mardu/bin/include/endian.h:37:23: note:
> place parentheses around the '+' expression to silence this warning
>         return __bswap32(__x)+0ULL<<32 | __bswap32(__x>>32);
>                              ^
>                (                  )

The compiler should not produce style warnings for macros expanded
from system headers, but I believe this is a known clang misfeature.
In any case this one is just a warning.

> perlio.c:2308:21: error: use of undeclared identifier 'O_TRUNC'; did
> you mean 'OP_TRANS'?
>         oflags = O_CREAT | O_TRUNC;
>                            ^~~~~~~
>                            OP_TRANS
> ../opnames.h:51:2: note: 'OP_TRANS' declared here
>         OP_TRANS,       /* 35 */
>         ^
> perlio.c:2318:21: error: use of undeclared identifier 'O_APPEND'
>         oflags = O_CREAT | O_APPEND;
>                            ^

No idea how O_CREAT was defined but O_TRUNC and O_APPEND were not.
This sounds like either perlio.h failed to include fcntl.h and
something else provided a fallback definition of O_CREAT, or you have
a corrupted installation of the musl headers.

> perlio.c:3046:28: error: incomplete definition of type 'struct _IO_FILE'
>         STDCHAR *eptr = (STDCHAR*)PerlSIO_get_ptr(s);
>                                   ^~~~~~~~~~~~~~~~~~
> ../iperlsys.h:305:29: note: expanded from macro 'PerlSIO_get_ptr'
> #define PerlSIO_get_ptr(f)              FILE_ptr(f)
>                                         ^~~~~~~~~~~
> ../spec_config.h:814:30: note: expanded from macro 'FILE_ptr'
> #   define FILE_ptr(fp) ((fp)->_IO_read_ptr)
>                          ~~~~^
> /home/c/workspace/research/mardu/bin/include/bits/alltypes.h:356:16:
> note: forward declaration of 'struct _IO_FILE'
> typedef struct _IO_FILE FILE;
>                ^
> perlio.c:3054:20: error: incomplete definition of type 'struct _IO_FILE'
>             if ((STDCHAR*)PerlSIO_get_ptr(s) != --eptr || ((*eptr &
> 0xFF) != ch)) {
>                           ^~~~~~~~~~~~~~~~~~
> ../iperlsys.h:305:29: note: expanded from macro 'PerlSIO_get_ptr'
> #define PerlSIO_get_ptr(f)              FILE_ptr(f)
>                                         ^~~~~~~~~~~

This code is trying to poke at glibc FILE structure internals and is
invalid. Depending on what it's trying to do there may or may not be a
valid way to achieve the same thing.

Rich


      reply	other threads:[~2018-10-14  1:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-13 21:47 K Jelesnianski
2018-10-14  1:51 ` Rich Felker [this message]

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=20181014015106.GH5150@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=kjski@vt.edu \
    --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).