Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Hans Aberg]

Guile-1.8.4 does not compile on Mac OS X 10.4.11 PPC G4 (see below).

   Hans Aberg


----
Making all in guile-readline
../libguile/guile-snarf -o readline.x readline.c -DHAVE_CONFIG_H  -I.  
-I.. -I./..  -g -O2
make  all-recursive
Making all in ice-9
make[4]: Nothing to be done for `all'.
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H  -I. - 
I. -I.. -I./..    -g -O2 -MT readline.lo -MD -MP -MF .deps/ 
readline.Tpo -c -o readline.lo readline.c
mkdir .libs
  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -g -O2 -MT readline.lo -MD - 
MP -MF .deps/readline.Tpo -c readline.c  -fno-common -DPIC -o .libs/ 
readline.o
readline.c: In function ‘rl_cleanup_after_signal’:
readline.c:109: error: ‘rl_pending_input’ undeclared (first use in  
this function)
readline.c:109: error: (Each undeclared identifier is reported only once
readline.c:109: error: for each function it appears in.)
readline.c: In function ‘scm_init_readline’:
readline.c:564: warning: assignment from incompatible pointer type
make[4]: *** [readline.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
----

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Ludovic Courtès]

Hi,

Hans Aberg <haberg@math.su.se> writes:

> Guile-1.8.4 does not compile on Mac OS X 10.4.11 PPC G4 (see below).

> readline.c:109: error: ‘rl_pending_input’ undeclared (first use in

As we already discussed, you'll want to install GNU Readline, as opposed
to the BSD Editline broken Readline compatibility layer that you're
currently using.

On one hand, it's become such a common problem that we may want to
detect it at configure-time.  OTOH, a compatibility layer is supposed to
be compatible, and it would be annoying to have to work around
Editline's defects.  :-)

Thanks,
Ludovic.

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Hans Aberg <haberg@math.su.se> writes:
>
>> Guile-1.8.4 does not compile on Mac OS X 10.4.11 PPC G4 (see below).
>
>> readline.c:109: error: ‘rl_pending_input’ undeclared (first use in
>
> As we already discussed, you'll want to install GNU Readline, as opposed
> to the BSD Editline broken Readline compatibility layer that you're
> currently using.
>
> On one hand, it's become such a common problem that we may want to
> detect it at configure-time.  OTOH, a compatibility layer is supposed to
> be compatible, and it would be annoying to have to work around
> Editline's defects.  :-)

I've started a FAQ (to be included in future Guile releases), and this
is the first entry:

=========>8===========
** readline.c: error: `rl_pending_input' undeclared

This occurs if the Readline library detected by Guile's configure
script is actually the BSD Editline project's supposedly
Readline-compatible library.  The immediate fix is to uninstall
Editline and install the real GNU Readline instead.  When you do this,
please note that it probably won't work to keep Editline in /usr and
install GNU Readline in /usr/local (or some similar arrangement),
because the Editline library will then still be picked up at link and
run time; it's best (subject to other constraints) to remove Editline
completely.

For the longer term, please also report this problem to the Editline
project, to encourage them to fix it in the next release of their
Readline compatibility library.
=========>8===========

Regards,
        Neil

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Neil Jerram]

Hans Aberg <haberg@math.su.se> writes:

> readline.c: In function ‘rl_cleanup_after_signal’:
> readline.c:109: error: ‘rl_pending_input’ undeclared (first use in
> this function)
> readline.c:109: error: (Each undeclared identifier is reported only once
> readline.c:109: error: for each function it appears in.)
> readline.c: In function ‘scm_init_readline’:
> readline.c:564: warning: assignment from incompatible pointer type
> make[4]: *** [readline.lo] Error 1
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

Hi Hans,

From our new FAQ (which will be part of the distribution in 1.8.5):

========FAQ=========
** readline.c: error: `rl_pending_input' undeclared

This occurs if the Readline library detected by Guile's configure
script is actually the BSD Editline project's supposedly
Readline-compatible library.  The immediate fix is to uninstall
Editline and install the real GNU Readline instead.  When you do this,
please note that it probably won't work to keep Editline in /usr and
install GNU Readline in /usr/local (or some similar arrangement),
because the Editline library will then still be picked up at link and
run time; it's best (subject to other constraints) to remove Editline
completely.

For the longer term, please also report this problem to the Editline
project, to encourage them to fix it in the next release of their
Readline compatibility library.
========FAQ=========

Does that help?

Regards,
        Neil

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Hans Aberg]

On 7 Mar 2008, at 20:55, Neil Jerram wrote:

> From our new FAQ (which will be part of the distribution in 1.8.5):
>
> ========FAQ=========
> ** readline.c: error: `rl_pending_input' undeclared
>
> This occurs if the Readline library detected by Guile's configure
> script is actually the BSD Editline project's supposedly
> Readline-compatible library.  The immediate fix is to uninstall
> Editline and install the real GNU Readline instead.  When you do this,
> please note that it probably won't work to keep Editline in /usr and
> install GNU Readline in /usr/local (or some similar arrangement),
> because the Editline library will then still be picked up at link and
> run time; it's best (subject to other constraints) to remove Editline
> completely.
>
> For the longer term, please also report this problem to the Editline
> project, to encourage them to fix it in the next release of their
> Readline compatibility library.
> ========FAQ=========
>
> Does that help?

This might indeed be the problem - I think I saw that Mac OS X comes  
with Editline.

I have since installed Readline; I need to check if it fixes it.

Otherwise, a fix might be that the Guile installation checks for  
readline in /usr/local/.

   Hans Aberg

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Neil Jerram]

Hans Aberg <haberg@math.su.se> writes:

> Otherwise, a fix might be that the Guile installation checks for
> readline in /usr/local/.

I could well be wrong, but my current understanding is that that won't
work, because at link time GCC or ld.so will always prefer to pick up
-lreadline from /usr/lib rather than from /usr/local/lib.

Regards,
     Neil

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Hans Aberg]

On 7 Mar 2008, at 23:21, Neil Jerram wrote:

>> Otherwise, a fix might be that the Guile installation checks for
>> readline in /usr/local/.
>
> I could well be wrong, but my current understanding is that that won't
> work, because at link time GCC or ld.so

(On Mac OS X, dynamic libraries end with .dylib, being a Mach-O  
format. The .so is for a fromat used on GNU/Linux computers.)

> will always prefer to pick up
> -lreadline from /usr/lib rather than from /usr/local/lib.

It could be, because the reason I installed latest readline was that  
I wanted Hugs and GHCi working with UTF-8, and it didn't work.

Suppose I set a soft link from the system readline to the newly  
installed, would it suffice to set it from
   /usr/lib/libreadline.<ext> -> /usr/local/lib/libreadline.<ext>
Or must some other stuff, like in /usr/include, also be relinked?

   Hans Aberg

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Neil Jerram]

Hans Aberg <haberg@math.su.se> writes:

> On 7 Mar 2008, at 23:21, Neil Jerram wrote:
>
>>> Otherwise, a fix might be that the Guile installation checks for
>>> readline in /usr/local/.
>>
>> I could well be wrong, but my current understanding is that that won't
>> work, because at link time GCC or ld.so
>
> (On Mac OS X, dynamic libraries end with .dylib, being a Mach-O
> format. The .so is for a fromat used on GNU/Linux computers.)

OK, thanks.

>> will always prefer to pick up
>> -lreadline from /usr/lib rather than from /usr/local/lib.
>
> It could be, because the reason I installed latest readline was that I
> wanted Hugs and GHCi working with UTF-8, and it didn't work.
>
> Suppose I set a soft link from the system readline to the newly
> installed, would it suffice to set it from
>   /usr/lib/libreadline.<ext> -> /usr/local/lib/libreadline.<ext>

Yes, that should work.  Sysadmin-wise, it's a confusing change to keep
track of, though.

> Or must some other stuff, like in /usr/include, also be relinked?

No, I don't think that will be needed.  As long as you have
CFLAGS=-I/usr/local/include when you run ./configure, I believe that
headers under /usr/local/include will be picked up in preference to
those under /usr/include.

(BTW, this is something that I've never seen a good explanation for.
-I/usr/local/include takes preference over the standard /usr/include,
but -L/usr/local/lib doesn't take preference over the standard
/usr/lib.  What is the logic there?)

Regards,
        Neil

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

[Hans Aberg]

On 8 Mar 2008, at 13:19, Neil Jerram wrote:

>> (On Mac OS X, dynamic libraries end with .dylib, being a Mach-O
>> format. The .so is for a fromat used on GNU/Linux computers.)
>
> OK, thanks.

For what I have checked, the functions are named the same. So if one  
assumes the dynamic libraries have been created on Mac OS X, the only  
change needed in the source code is to look for files ending  
in .dylib instead of .so.

>>> will always prefer to pick up
>>> -lreadline from /usr/lib rather than from /usr/local/lib.
>>
>> It could be, because the reason I installed latest readline was  
>> that I
>> wanted Hugs and GHCi working with UTF-8, and it didn't work.
>>
>> Suppose I set a soft link from the system readline to the newly
>> installed, would it suffice to set it from
>>   /usr/lib/libreadline.<ext> -> /usr/local/lib/libreadline.<ext>
>
> Yes, that should work.  Sysadmin-wise, it's a confusing change to keep
> track of, though.

Yes, it is a mess. :-)

>> Or must some other stuff, like in /usr/include, also be relinked?
>
> No, I don't think that will be needed.  As long as you have
> CFLAGS=-I/usr/local/include when you run ./configure, I believe that
> headers under /usr/local/include will be picked up in preference to
> those under /usr/include.
>
> (BTW, this is something that I've never seen a good explanation for.
> -I/usr/local/include takes preference over the standard /usr/include,
> but -L/usr/local/lib doesn't take preference over the standard
> /usr/lib.  What is the logic there?)

It is certainly causing problems. Somebody got problems on the GMP  
list reported problems with that package and Guile (Mac OS X 10.5  
Intel perhaps). But it strikes me now, in view of your letters, that  
it might be due to the same issue as with readlib.

Do you happen to know with there are any environment variables one  
might set for GCC, like LIBPATH, INCLUDEPATH, or something, that  
ensures /usr/local is included? This would be a convenient method.

   Hans Aberg