[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSK(OSS) compilation problem
From: |
mwoehlke |
Subject: |
Re: NSK(OSS) compilation problem |
Date: |
Wed, 11 Oct 2006 14:02:15 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 |
Paul Eggert wrote:
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).
I was hoping someone else could slip in the 'configure needs to write a
replacement for HAVE_UNSIGNED_LONG_LONG_INT'. :-) I would have thought
this is a one-line, trivial change?
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.
Well, the question was "am I ok telling coreutils to not build
sha512.c?". I'll take that as a "yes", thanks!
(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.
Oops, I meant "NNTP"; I'm using gmane.org. What I meant was that I
expect the roots of the post to start being culled, but I guess I'll
just ignore that/live with it.
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.
No, in *this* case (and it is a strange one), the problem is that
_TANDEM_SOURCE is not defined; not by missing headers. I can verify this
with:
$ CFLAGS=-D_TANDEM_SOURCE ./configure
...
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
...
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
...
...but I don't feel that this is an ideal solution. I would prefer that
autoconf know that if it is on NSK/OSS ('#ifdef __TANDEM'), that
_TANDEM_SOURCE needs to be defined. I.e. I would add an early check that
would toss '-D_TANDEM_SOURCE' into CFLAGS, and of course use that value
as it goes on to try its test programs.
Meanwhile, however, I am going to keep going without to see what
individual sources trip over this, unless I hear agreement that autoconf
should be fixed. (I would guess this impacts quite a few packages, and
not just coreutils.)
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.
If you see the aforementioned bug report, it must be defined for a
number of headers to compile correctly... including sys/types.h (see
next comment), and also sys/statvfs.h and sys/ioctl.h (see above).
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.
sys/types.h defines u_*, but *only if _TANDEM_SOURCE is defined*. No
header in /usr/include defines this, but *all* of these test for it:
/usr/include/ctype.h
/usr/include/dirent.h
/usr/include/fcntl.h
/usr/include/fnmatch.h
/usr/include/limits.h
/usr/include/locale.h
/usr/include/netdb.h
/usr/include/netinet/in.h
/usr/include/nl_types.h
/usr/include/pwd.h
/usr/include/signal.h
/usr/include/stdio.h
/usr/include/stdlib.h
/usr/include/string.h
/usr/include/stropts.h
/usr/include/sys/ipc.h
/usr/include/sys/socket.h
/usr/include/sys/types.h
/usr/include/sys/uio.h
/usr/include/sys/un.h
/usr/include/sys/wait.h
/usr/include/termios.h
/usr/include/unistd.h
/usr/include/wchar.h
I'm attaching sys/types.h so you can take a look, but just in case the
horse isn't dead enough yet, /please/ just trust me that this *needs* to
be defined :-).
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.
Thanks, I'll pull my changes to the affected files and try out your
patch(es). If I am seeing correctly, however, aren't you missing patches
to Makefile.in and configure (or rather sources there-to) so that
@HAVE_UNSIGNED_LONG_LONG_INT@ is substituted correctly? Unless I am
mistaken, without these the generated source file will wind up with
literal '@HAVE_UNSIGNED_LONG_LONG_INT@' in it.
And thanks again for all the help; I really appreciate that you're
willing to help support an exotic platform like this. :-)
--
Matthew
Will your shell have salvation? Only if it's Bourne Again.
#ifdef __TANDEM
#pragma columns 80
#if _TANDEM_ARCH_ != 0
#pragma ONCE
#endif
#endif
#ifndef _SYS_TYPES
#define _SYS_TYPES
/* T8645G08 - (16MAY2003) - sys/types.h basic system types */
/*
* Copyright 2003 Compaq Computer Corporation
*
* ALL RIGHTS RESERVED
*/
#ifdef __cplusplus
extern "C" {
#endif
/*
* In the OSS File System some of the definitions are 64-bit wide.
* In Guardian C there is support of 64-bit wide variables declared
* using long long. To allow the same width on the workstation we will
* use double. The definition can be sourced in using the ifdef switch.
*/
#ifdef __TANDEM
#define int64_t long long
#else
typedef double int64_t;
#endif
#ifndef __clock_t_DEFINED
#define __clock_t_DEFINED
typedef int64_t clock_t; /* Used for sys time in clock ticks */
#endif
typedef int64_t dev_t; /* <old device number> type */
typedef long gid_t; /* group id */
#ifdef _XOPEN_SOURCE_EXTENDED
#ifndef __id_t_DEFINED
#define __id_t_DEFINED
typedef int id_t; /* Can hold gid_t, pid_t, or uid_t */
#endif
#endif /* _XOPEN_SOURCE_EXTENDED */
typedef long ino_t; /* <inode> type */
typedef int key_t; /* IPC Key */
typedef unsigned long mode_t;
typedef short nlink_t;
#ifndef __off_t_DEFINED
#define __off_t_DEFINED
typedef long off_t; /* file offset (signed number) */
#endif
typedef int pid_t; /* process id (signed number) */
#ifndef __size_t_DEFINED
#define __size_t_DEFINED
#if _TANDEM_ARCH_ != 0 || !defined(__TANDEM)
typedef unsigned int size_t;
#else /* _TANDEM_ARCH_ == 0 */
#if !defined(_GUARDIAN_TARGET) || defined(__XMEM)
typedef unsigned long size_t;
#else
typedef unsigned short size_t;
#endif
#endif /* _TANDEM_ARCH_ == 0 */
#endif /* __size_t_DEFINED */
#ifndef __ssize_t_DEFINED
#define __ssize_t_DEFINED
#if _TANDEM_ARCH_ != 0 || !defined(__TANDEM)
typedef int ssize_t;
#else /* _TANDEM_ARCH_ == 0 */
#if !defined(_GUARDIAN_TARGET) || defined(__XMEM)
typedef long ssize_t;
#else
typedef short ssize_t;
#endif
#endif /* _TANDEM_ARCH_ == 0 */
#endif /* __ssize_t_DEFINED */
#ifndef __time_t_DEFINED
#define __time_t_DEFINED
typedef long time_t; /* time in seconds */
#endif
typedef long uid_t; /* user id */
#ifdef _TANDEM_SOURCE
#ifndef __caddr_t_DEFINED
#define __caddr_t_DEFINED
typedef char *caddr_t;
#endif
typedef unsigned char uchar_t;
typedef unsigned int uint_t;
#ifndef _tcp_TYPES
#define _tcp_TYPES
typedef unsigned char u_char;
typedef unsigned short u_short;
typedef unsigned int u_int;
typedef unsigned long u_long;
typedef unsigned short ushort;
#endif /* _tcp_TYPES */
#ifndef __daddr_t_DEFINED
#define __daddr_t_DEFINED
typedef long daddr_t;
#endif
#ifndef __NBBY_DEFINED
#define __NBBY_DEFINED
#define NBBY 8 /* number of bits in a byte */
#endif
#ifndef howmany
#define howmany(x, y) (((x)+((y)-1))/(y))
#endif
#endif /* _TANDEM_SOURCE */
#ifdef __cplusplus
}
#endif
#endif /* _SYS_TYPES defined */
- 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, 2006/10/11
- Re: NSK(OSS) compilation problem,
mwoehlke <=
- 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
- Message not available
- Re: proposed patch to allocsa, vasnprintf for Tandem NSK (OSS), Paul Eggert, 2006/10/11