From: "Игорь Пашев" <pashev.igor@gmail.com>
To: libc-ports@sourceware.org
Subject: ../nptl/sysdeps/x86_64/tls.h:71:3: error: unknown type name '__m128
Date: Thu, 23 May 2013 07:15:00 -0000 [thread overview]
Message-ID: <CALL-Q8wGPNpBOvZaWOQOyQ2Ot4-M7EMV0dxv5pmBXoo0R2Ukzw@mail.gmail.com> (raw)
Hi, all!
First off, i'm going forward porting glibc on illumos kernel (aka OpenSolaris).
The port is based on glibc 2.16.
I know, that __m128 was replaced by hand-made type in
nptl/sysdeps/x86_64/tls.h [1], because rtld
is compiled without sse.
But I'd like to figure out how it worked previously, and whether there
are other bugs in my port.
Here is compiler message:
============= >8 ===================
gcc ../sysdeps/x86_64/multiarch/strstr.c -c -std=gnu99 -fgnu89-inline
-O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants
-frounding-math -g -Wstrict-
-msse4 -I../include -I/home/pashev/glibc/build/string
-I/home/pashev/glibc/build
-I../nptl/sysdeps/unix/sysv/solaris2/kopensolaris-gnu/x86_64 -I../np
unix/sysv/solaris2/kopensolaris-gnu/x86
-I../sysdeps/unix/sysv/solaris2/kopensolaris-gnu/x86
-I../sysdeps/unix/sysv/solaris2/kopensolaris-gnu/x86_64 -I../np
unix/sysv/solaris2/kopensolaris-gnu -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../sysdeps/unix/sysv/solaris2/kopensolaris-gnu
-I../sysdeps/gnu -I../sy
inet -I../nptl/sysdeps/unix/sysv/solaris2
-I../sysdeps/unix/sysv/solaris2 -I../nptl/sysdeps/unix/sysv
-I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../n
/unix -I../sysdeps/unix -I../sysdeps/posix -I../nptl/sysdeps/x86_64/64
-I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch
-I../sysdeps/x86_64/fpu -I..
6_64/multiarch -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64
-I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysde
dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64
-I../sysdeps/ieee754 -I../sysdeps/generic -I../nptl -I.. -I../libio
-I. -D_LIBC_REENTRANT -inc
lude/libc-symbols.h -o /home/pashev/glibc/build/string/strstr.o
-MD -MP -MF /home/pashev/glibc/build/string/strstr.o.dt -MT
/home/pashev/glibc/build/s
r.o
In file included from
../nptl/sysdeps/unix/sysv/solaris2/kopensolaris-gnu/tls.h:31:0,
from ../include/errno.h:22,
from
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/mm_malloc.h:28,
from
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/xmmintrin.h:39,
from
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/emmintrin.h:36,
from
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/pmmintrin.h:36,
from
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/tmmintrin.h:35,
from
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/smmintrin.h:36,
from
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/nmmintrin.h:34,
from ../sysdeps/x86_64/multiarch/strstr.c:20:
../nptl/sysdeps/x86_64/tls.h:71:3: error: unknown type name '__m128'
============= 8< ===================
The "nptl/sysdeps/x86_64/tls.h" includes "xmmintrin.h" for __m128 [2],
but from the above output it is obvious, that is already included. But
this file defines __m128
*after* including mm_malloc.h and thus errno.h and tls.h.
So "xmmintrin.h" is not included in "nptl/sysdeps/x86_64/tls.h".
Here is top of /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/xmmintrin.h:
================= >8 ===============
#ifndef _XMMINTRIN_H_INCLUDED
#define _XMMINTRIN_H_INCLUDED
#ifndef __SSE__
# error "SSE instruction set not enabled"
#else
/* We need type definitions from the MMX header file. */
#include <mmintrin.h>
/* Get _mm_malloc () and _mm_free (). */
#include <mm_malloc.h>
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
================= 8< ===============
The "/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include/mm_malloc.h" file
includes errno.h for one of inline functions.
I've compared it with linux mm_malloc.h: the latter does not include errno.h.
So the problem is specific to OpenSolaris.
What is the best way to fix it? Is it safe to backport [1] ? Should I
fix GCC headers?
Or maybe include/errno.h is not that errno.h file which should be included?
[1] http://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nptl/sysdeps/x86_64/tls.h;h=bc60a511fbc0555f069888dc977ce39bd5326a46;hp=b651d1cfa8840cfa4f27aa197c82e8f01625b191;hb=f62c8abcfbf0d2e7f0a6c6c1dde53158e6fc4e59;hpb=a68d0680f89b5f3639b30ec7955671d97e101e87
[2] http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/sysdeps/x86_64/tls.h;h=b651d1cfa8840cfa4f27aa197c82e8f01625b191;hb=b651d1cfa8840cfa4f27aa197c82e8f01625b191
reply other threads:[~2013-05-23 7:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CALL-Q8wGPNpBOvZaWOQOyQ2Ot4-M7EMV0dxv5pmBXoo0R2Ukzw@mail.gmail.com \
--to=pashev.igor@gmail.com \
--cc=libc-ports@sourceware.org \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).