bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling v1.8.5 on tru64 5.1b


From: Neil Jerram
Subject: Re: Compiling v1.8.5 on tru64 5.1b
Date: Tue, 13 May 2008 00:34:21 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Didier Godefroy <address@hidden> writes:

>>> cc: Error: eval.c, line 2363: In this statement, "*(SCM
>>> ...)0=(((SCM)((((0))<<8)+scm_tc8_isym)))" is not constant, but occurs in a
>>> context that requires a constant expression. (needconstexpr)
>>>     case (ISYMNUM (SCM_IM_AND)):
>> 
>> Are you using a somewhat dated compiler?  scm_tc8_isym is defined
>
> The compiler is the Tru64 v5.1b native:
>
> cc -V
> Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650)
> Compiler Driver V6.5-003 (sys) cc Driver

Circa 2003, as far as I make out from google.

> That's what we (tru64 users) always use for just about everything.
> Very few packages will force us to use gcc.

But is using GCC a major problem for you?  If it works, and the native
compiler doesn't, surely that's the easy solution?

(FWIW, Guile does build with a handful of modern compilers, e.g. the
Intel, Sun and IBM compilers, not just GCC.  So I really think that
this is more a problem of the Tru64 compiler being too old, rather
than of Guile being too GCC-dependent.)

> Ok, here is what it gives me now:
>
> cc -pthread -DHAVE_CONFIG_H -I.. -I.. -I.. -D_REENTRANT -O4 -g3
> -I/usr/local/gmp/include -I/usr/local/readline/include -c -MD error.c  -DPIC
> -o .libs/libguile_la-error.o
> cc: Warning: error.c, line 66: Non-void function "scm_error_scm" does not
> contain a return statement. (missingreturn)
> SCM_DEFINE (scm_error_scm, "scm-error", 5, 0, 0,
> ^

Problem here is the compiler not working out that the function will
never return.  Can fix this by adding "return SCM_UNSPECIFIED;" (which
will never actually be executed) at the end of scm_error_scm().

> cc: Error: eval.c, line 2363: In this statement, "*(SCM
> ...)0=(((SCM)((((0))<<8)+(4+0X0000000000000010))))" is not constant, but
> occurs in a context that requires a constant expression. (needconstexpr)
>     case (ISYMNUM (SCM_IM_AND)):
> ----------^

OK, please try building with -DSCM_DEBUG_TYPING_STRICTNESS=0.
(I think you can do this by running configure as:

 CFLAGS=-DSCM_DEBUG_TYPING_STRICTNESS=0 ./configure [your usual args]

It may also work to do 'make clean; make
CFLAGS=-DSCM_DEBUG_TYPING_STRICTNESS=0', but I'm not sure about that.)

Hopefully then the compiler will realize that the ISYMNUM(...)
expressions are constant!

>> problems?  Can you also tell us about your compiler, and if there is a
>> C preprocessor macro that can be used to detect it dynamically?
>
> I don't know much about c to handle this, maybe if you tell me what to look
> for, I can help. Maybe by looking at some other package to see how they
> handle it..

I guess we need to see first if it proves tractable to compile with
Tru64 (which is looking harder than I thought when I wrote the words
just above).  If it does, we can then look at how to formalize the
changes.

> And one more small detail, just in case you want to clean up some code,
> there are a bunch of info msgs from the compiler, just a bit before getting
> the errors:
>
> cc -pthread -DHAVE_CONFIG_H -I.. -I.. -I.. -D_REENTRANT -O4 -g3
> -I/usr/local/gmp/include -I/usr/local/readline/include -c -MD discouraged.c
> -DPIC -o .libs/libguile_la-discouraged.o
> cc: Info: discouraged.c, line 30: Extraneous semicolon. (extrasemi)
> DEFFROM (short, scm_short2num, scm_from_short);
> ----------------------------------------------^

Thanks, I've fixed those.  Patch attached.

    Neil

Attachment: 0001-Expand-DEFFROM-and-DEFTO-macros-in-discouraged.c.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]