From: Dan Kegel <dank@kegel.com>
To: linux-kernel@vger.kernel.org
Cc: kaz Kojima <kkojima@rr.iij4u.or.jp>
Subject: [PATCH] Hide struct ustat in include/linux/types.h from userspace?; needed to build glibc-2.3.2 on sh4
Date: Sat, 21 Jun 2003 20:10:23 -0700 [thread overview]
Message-ID: <3EF51E1F.9000701@kegel.com> (raw)
I have to apply the following patch, kindly sent to me by
Kaz Kojima, to the 2.4.19/2.4.20 kernel in
order to build glibc-2.3.2 for the sh4 processor.
All it does is hide the kernel's definition of struct ustat
from userspace. This prevents a clash with the userspace
definition of struct ustat.
I verified this has not yet been applied as of 2.4.22-pre1.
I'm not familiar enough with the kernel/c-library interface to
know whether this patch is the proper fix, but it's the one
being used by the sh-linux folks.
The symptom without this patch is:
In file included from sys/ustat.h:30,
from ../sysdeps/unix/sysv/linux/ustat.c:21:
../sysdeps/generic/bits/ustat.h:26: error: redefinition of `struct ustat'
make[2]: *** [/build/sh4-unknown-linux-gnu/gcc-3.3-glibc-2.3.2/build-glibc/misc/ustat.o] Error 1
make[2]: Leaving directory `/build/sh4-unknown-linux-gnu/gcc-3.3-glibc-2.3.2/glibc-2.3.2/misc'
Yeah, I know the sh folks have their own kernel tree, but IMHO
one ought at least be able to build working toolchains with the
vanilla vger kernel headers. I now have a script that builds
cross-toolchains for many architectures from scratch at
http://kegel.com/crosstool
and I'm trying to nudge patches into the main trees of gcc, glibc, and linux
so their next vanilla releases can be used to build working
cross-compilers targeting every architecture glibc supports
without patches.
- Dan
diff -u linux-2.5.69-sf-orig/include/linux/types.h /usr/local/sh4-unknown-linux-gnu/include/linux/types.h
--- linux-2.5.69-sf-orig/include/linux/types.h Wed Mar 5 12:29:34 2003
+++ sh4-unknown-linux-gnu/include/linux/types.h Sat Apr 19 10:05:52 2003
@@ -141,6 +141,7 @@
#endif /* __KERNEL_STRICT_NAMES */
+#ifdef __KERNEL__
/*
* Below are truly Linux-specific types that should never collide with
* any application/library that wants linux/types.h.
@@ -152,5 +153,6 @@
char f_fname[6];
char f_fpack[6];
};
+#endif
#endif /* _LINUX_TYPES_H */
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
reply other threads:[~2003-06-22 2:46 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=3EF51E1F.9000701@kegel.com \
--to=dank@kegel.com \
--cc=kkojima@rr.iij4u.or.jp \
--cc=linux-kernel@vger.kernel.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