SGI: Development

m4 ...

Building a new Irix setup, at 6.5.21 now, it's clean and pretty and fast and it actually prints, which has been a nightmare ever since that cups fiasco. Installed MIPSPro 7.4.4. As a test I tried reproducing some of the most basic gnu programs in nekoware.

We're not up to gnumake yet, using Irix make

libsigsev went fine and passed all tests, too

m4 ... initially done as a simple ./configure --prefix=/usr/nekoware. That built and tested fine. Then I went and checked the neko release notes. Hmm, the original person configured as

Code: Select all

./configure --prefix=/usr/nekoware --enable-threads=posix --enable-c++

Okay. let's try that.

Configured fine. Built fine. But the tests ... :(

Code: Select all

cc-1132 CC: ERROR File = /usr/include/sys/types.h, Line = 536
The namespace "std" has no member "time_t".

__SGI_LIBC_USING_FROM_STD(time_t)
^

cc-1132 CC: ERROR File = /usr/include/sys/types.h, Line = 537
The namespace "std" has no member "clock_t".

__SGI_LIBC_USING_FROM_STD(clock_t)
^

cc-1132 CC: ERROR File = /usr/include/internal/time_core.h, Line = 221
The namespace "std" has no member "time_t".

extern int cftime(char *, char *, const __SGI_LIBC_NAMESPACE_QUALIFIER time_t *);
^

cc-1132 CC: ERROR File = /usr/include/internal/time_core.h, Line = 231
The namespace "std" has no member "time_t".

extern char *ctime_r(const __SGI_LIBC_NAMESPACE_QUALIFIER time_t *, char *);
^

cc-1132 CC: ERROR File = /usr/include/internal/time_core.h, Line = 232
The namespace "std" has no member "time_t".

extern struct tm *gmtime_r(const __SGI_LIBC_NAMESPACE_QUALIFIER time_t *,
^

cc-1132 CC: ERROR File = /usr/include/internal/time_core.h, Line = 234
The namespace "std" has no member "time_t".

extern struct tm *localtime_r(const __SGI_LIBC_NAMESPACE_QUALIFIER time_t *,
^

cc-1132 CC: ERROR File = /usr/include/time.h, Line = 7
The namespace "std" has no member "clock_t".

__SGI_LIBC_USING_FROM_STD(clock_t)
^

cc-1132 CC: ERROR File = /usr/include/time.h, Line = 8
The namespace "std" has no member "time_t".

__SGI_LIBC_USING_FROM_STD(time_t)
^

cc-1174 CC: WARNING File = test-sys_time-c++.cc, Line = 28
The variable "signature_check28" was declared but never referenced.

SIGNATURE_CHECK (GNULIB_NAMESPACE::gettimeofday, int,
^

8 errors detected in the compilation of "test-sys_time-c++.cc".
*** Error code 2 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)

Rebuilt it without the c++ portion, it now pases all the tests (except for the skipped ones, which get skipped, no biggy.)

Not sure what is going on here ? Is this a version thing, where this version is newer than what's in nekoware, so it's doing new things ? Or doesn't it matter for what we normally do, which is just running autoconf, so failing many of the c++ tests never showed up ? Or have there been errors hiding in the most basic nekoware for a decade cuz the original guy never ran make check to see these failures ?

Anybody got any idears ? As far as I can think, the lack of c++ won't affect us but informed opinion is welcome.
Juliet ! the dice were loaded from the start ...
it just seems to lack the time.h header
r-a-c.de
I took a quick look at the source, and the only C++ source files I could find are all in the tests/ directory. It looks to me like m4 is just using the C++ compiler to build some files that test function signatures. (E.g., the test-sys_time-c++.cc that hamei's post mentions just checks that gettimeofday takes "struct timeval *" and "void *" parameters and returns "int", AFAICT.)

I don't see any loss of functionality by skipping the C++ stuff.
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500
HP C8000
jpstewart wrote: I don't see any loss of functionality by skipping the C++ stuff.

Thank y'all. I didn't see a problem either but would rather run the question by some people who know what they are doing :D Also rebuilt it without the C++ "support".

Anyhoo ... kinda related. Thought while I was here I'd rebuild the basics at the newest version levels. Are there any known gotchas ? Stuff like this scares me :

delorie.com wrote: The last release of libltdl used some symbols that violated the POSIX namespace conventions. These symbols are now deprecated, and have been replaced by those described here.

Use of the word "deprecated" gives me shivers, usually it means "no longer works" .... The newest libsigsev built okay and gmake 4.1 too but I'm wondering if there are known hidden gotchas in any of the basic tools ? Autoconf, libtool, gmake, etc ?


btw, a clean 6.5.21 without the triple-layer of spooge is very nice. 2x400 works very good, I don't even feel too sad about speed.
Juliet ! the dice were loaded from the start ...