[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSK(OSS) compilation problem
From: |
Paul Eggert |
Subject: |
Re: NSK(OSS) compilation problem |
Date: |
Tue, 10 Oct 2006 23:08:24 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
mwoehlke <address@hidden> writes:
> Ok... Attaching an initial attempt at a patch for stdint_.h. The
> configure script (or more appropriately, I suppose, configure.in)
> needs to be patched additionally, but alas, I do not speak autotools
> :-)
I'm afraid you'll have to get up to speed with them in order to do
reasonable development in this area. You don't have to port the
autotools to NSK(OSS); just run them on a GNU/Linux host, do a "make
dist" and then unpackage the tar image on NSK(OSS).
> Anyway, this got me as far as sha512.c where the compiler croaked with:
Fundamentally the problem is that sha512 assumes a 64-bit unsigned
integer type, and you don't have one. I guess the best way to fix
this is to change coreutils to not build sha512 on hosts that don't
have uint64_t.
> (So, yes... "yike"... Since this thread is already getting old (and
> likely to get a lot older before I'm done), should I continue this
> thread even if/when it starts falling off NTP, or start new ones?)
I don't know what you mean by "NTP", but we're always interested in
ports to real hosts, and Tandem/NSK OSS qualifies as a real host in my
book. The thread is still live on
<http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00062.html>,
if that's what you mean.
> On an unrelated note, when running configure, I get these two header
> compilation failures:
>
> ...
> configure: WARNING: sys/statvfs.h: present but cannot be compiled
> ...
> configure: WARNING: sys/ioctl.h: present but cannot be compiled
> ...
This indicates that our tests for sys/ioctl.h and sys/statvfs.h are
neglecting to include some prerequisite include files. I cannot
reproduce the problem with CVS coreutils on Solaris 10 (using Sun C
5.8), so I guess the problem is fixed now. If not, you'll have to
send us more info.
> My guess, however, is that this is a case of
> needing _TANDEM_SOURCE defined ala
> http://savannah.gnu.org/bugs/?17172, but since this would need to be
> changed in autoconf I'm not sure what, if anything, should or could be
> done.
Can you give more information about this? What is _TANDEM_SOURCE
used for? You can check the files under /usr/include to find out.
> For statvfs.h:
> "/usr/include/sys/statvfs.h", line 50: error(114): identifier "u_long"
> is undefined
What include file is supposed to define u_long? Use "grep -r u_long
/usr/include" to find out. Similary for ioctl.h.
The patch you sent was incomplete. I'm afraid I didn't really look at
it much; instead, I constructed another patch from first principles,
which I'll send in two later emails.
- NSK(OSS) compilation problem, mwoehlke, 2006/10/04
- Re: NSK(OSS) compilation problem, Paul Eggert, 2006/10/05
- Re: NSK(OSS) compilation problem, mwoehlke, 2006/10/06
- Re: NSK(OSS) compilation problem, Paul Eggert, 2006/10/06
- Re: NSK(OSS) compilation problem, mwoehlke, 2006/10/09
- Re: NSK(OSS) compilation problem,
Paul Eggert <=
- Re: NSK(OSS) compilation problem, mwoehlke, 2006/10/11
- Re: NSK(OSS) compilation problem, Paul Eggert, 2006/10/11
- Re: NSK(OSS) compilation problem (change to m4/extensions.m4), Paul Eggert, 2006/10/11
- Message not available
- Re: NSK(OSS) compilation problem (change to m4/extensions.m4), Ralf Wildenhues, 2006/10/12
- Re: NSK(OSS) compilation problem, Paul Eggert, 2006/10/11
- Re: NSK(OSS) compilation problem, Paul Eggert, 2006/10/11
- proposed patch to allocsa, vasnprintf for Tandem NSK (OSS), Paul Eggert, 2006/10/11
- Re: [bug-gnulib] proposed patch to allocsa, vasnprintf for Tandem NSK (OSS), Bruno Haible, 2006/10/11
- Re: [bug-gnulib] proposed patch to allocsa, vasnprintf for Tandem NSK (OSS), Bruno Haible, 2006/10/11
- Re: [bug-gnulib] proposed patch to allocsa, vasnprintf for Tandem NSK (OSS), mwoehlke, 2006/10/11