Neil Jerram | 1 May 11:11 2008
Picon

Re: Guile 1.8.4 build difficulties on old Linux

ludo <at> gnu.org (Ludovic Courtès) writes:

>> Line 194 of pthread.h (of Gnu PTH 2.0.7) is "typedef int socklen_t;",
>> the platform doesn't have socklen_t otherwise. Problem workaround by
>> --disable-error-on-warning.
>
> Isn't that a GNU Pth problem (that its header contains an "empty
> declaration")?

How is "typedef int socklen_t;" an empty declaration, anyway?  It
looks like a normal typedef to me.

Regards,
     Neil

Ludovic Courtès | 7 May 20:27 2008
Picon

Re: Link to GEE project page

Hi,

FYI, I removed references to GEE from the web page, although I'd be
happy if someone took it over...

Thanks,
Ludovic.

Attachment (,,remove-gee.diff): text/x-patch, 3253 bytes
Levine, Zachary | 7 May 17:55 2008

Bug 17344 lives

Hello.  I am installing guile-1.8.4 on a Red Hat Enterprise Linux system using KDE 3.5.4-13.el5 Red Hat.  (I hope that’s the operating system and not just KDE.  It also says “Fedora Core”.)   The system is a 64-bit Dell dual processor.

 

There was a bug reported in version 1.8.0, and a proposed fix under the subject “Re: [bug #17344] problem compiling guile 1.8.0”.  The fix given in that message worked (I think).  The point of this note is that it’s still a problem a couple of versions later.

 

Zachary Levine

Physicist, NIST

 

Neil Jerram | 9 May 00:12 2008
Picon

Re: Bug 17344 lives

"Levine, Zachary" <zlevine <at> nist.gov> writes:

> There was a bug reported in version 1.8.0,

guile.c:(.text+0x2f): undefined reference to `lt__PROGRAM__LTX_preloaded_symbols'

This happens when libguile tries to link against a more recent version
of libltdl than we're expecting.

> and a proposed fix under the subject
> ?Re: [bug #17344] problem compiling guile 1.8.0?.  The fix given in that
> message worked (I think).

What was the fix?  I couldn't track it down.  (Apart from "rerun more
up to date autotools".  We'd prefer to avoid that for now if
possible.)

>  The point of this note is that it?s still a problem
> a couple of versions later.

Thank you.  (One can't have too many reminders.)

Regards,
     Neil

Marijn Schouten (hkBst | 9 May 01:15 2008
Picon

Re: Bug 17344 lives


Neil Jerram wrote:
| "Levine, Zachary" <zlevine <at> nist.gov> writes:
|
|> There was a bug reported in version 1.8.0,
|
| guile.c:(.text+0x2f): undefined reference to `lt__PROGRAM__LTX_preloaded_symbols'
|
| This happens when libguile tries to link against a more recent version
| of libltdl than we're expecting.
|
|> and a proposed fix under the subject
|> ?Re: [bug #17344] problem compiling guile 1.8.0?.  The fix given in that
|> message worked (I think).
|
| What was the fix?  I couldn't track it down.  (Apart from "rerun more
| up to date autotools".  We'd prefer to avoid that for now if
| possible.)

Possible patch [1] that fixes this from bug [2].

|>  The point of this note is that it?s still a problem
|> a couple of versions later.
|
| Thank you.  (One can't have too many reminders.)
|
| Regards,
|      Neil
|

[1]: http://bugs.gentoo.org/attachment.cgi?id=145645
[2]: http://bugs.gentoo.org/show_bug.cgi?id=212723

Marijn

--
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
Neil Jerram | 10 May 00:27 2008
Picon

Re: Bug 17344 lives

"Marijn Schouten (hkBst)" <hkBst <at> gentoo.org> writes:

> Possible patch [1] that fixes this from bug [2].
>
> [1]: http://bugs.gentoo.org/attachment.cgi?id=145645
> [2]: http://bugs.gentoo.org/show_bug.cgi?id=212723

OK, but that just breaks pre-opening completely, doesn't it?

What's the underlying issue here?  Has libtool 2 dropped support for
pre-opening, or is there a different incantation needed for loading
pre-opened symbols, or is there something about Guile's build that
prevents libltdl from exporting lt__PROGRAM__LTX_preloaded_symbols?

Perhaps the point is that when libltdl was built, it knew it was for a
platform that supported proper dlopen, and hence that pre-opening
support should never be needed?  In that case, is there a
configure-time test we can do to discover whether the available
libltdl has pre-opening support or not?

Thanks,
    Neil

Ludovic Courtès | 11 May 05:15 2008
Picon

Re: Bug 17344 lives

Hi,

Neil Jerram <neil <at> ossau.uklinux.net> writes:

> What's the underlying issue here?  Has libtool 2 dropped support for
> pre-opening, or is there a different incantation needed for loading
> pre-opened symbols, or is there something about Guile's build that
> prevents libltdl from exporting lt__PROGRAM__LTX_preloaded_symbols?

I think we should have been using the `LTDL_SET_PRELOADED_SYMBOLS ()'
macro instead of having these two lines in `guile.c' (per node "Libltdl
interface" in the Libtool 1.5 manual).  Maybe this would work better
with 2.2 as it's still documented:

  http://www.gnu.org/software/libtool/manual/html_node/Dlpreopening.html

Thanks,
Ludovic.

Neil Jerram | 13 May 01:34 2008
Picon

Re: Compiling v1.8.5 on tru64 5.1b

Didier Godefroy <ldg <at> ulysium.net> 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

Ludovic Courtès | 14 May 06:37 2008
Picon

Re: Compiling v1.8.5 on tru64 5.1b

Hi,

Neil Jerram <neil <at> ossau.uklinux.net> writes:

> --- a/libguile/ChangeLog
> +++ b/libguile/ChangeLog
>  <at>  <at>  -1,3 +1,9  <at>  <at> 
> +2008-05-12  Neil Jerram  <neil <at> ossau.uklinux.net>
> +
> +	* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
> +	compiler warnings about excess semicolons.  (Reported by Didier
> +	Godefroy.)

Why didn't you just remove the trailing semicolons?  :-)

Thanks,
Ludovic.

Neil Jerram | 14 May 09:01 2008
Picon

Re: Compiling v1.8.5 on tru64 5.1b

ludo <at> gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil <at> ossau.uklinux.net> writes:
>
>> --- a/libguile/ChangeLog
>> +++ b/libguile/ChangeLog
>>  <at>  <at>  -1,3 +1,9  <at>  <at> 
>> +2008-05-12  Neil Jerram  <neil <at> ossau.uklinux.net>
>> +
>> +	* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
>> +	compiler warnings about excess semicolons.  (Reported by Didier
>> +	Godefroy.)
>
> Why didn't you just remove the trailing semicolons?  :-)

Because that messes up Emacs's C mode indentation.

I agree that that's an Emacs bug - as opposed to a bug with the code
as it was - but in the end I thought "hey, this is discouraged code,
so probably no one will ever touch it again, so does it really matter
whether we keep those DEFFROM and DEFTO macros or not?"

I spent a little time first, looking for a way of customizing
C mode to make it think that DEFFROM and DEFTO are always top-level;
but couldn't find one.

Regards,
     Neil


Gmane