4.2.4 failure on MacOS X

4.2.4 failure on MacOS X

[Peter Stephenson]

Just got this... looks like the iconv changes for Cygwin caused other
problems.

pws

From: William Scott <wgscott@chemistry.ucsc.edu>
Subject: zsh 4.2.4 build failure
Date: Thu, 3 Feb 2005 08:00:43 -0800
To: Peter Stephenson <pws@csr.com>

Dear Peter:

I built 4.2.3 on a new OS X machine yesterday without any problems.  
Today after seeing your email I tried to build 4.2.4 using an identical 
procedure (configure command just obtained from the history stack) and 
it fails like this:

gcc -Wl,-x   -o zsh main.o  `cat stamp-modobjs`   -L/sw/lib -lpcre -ldl 
-ltinfo -lm  -lc
ld: Undefined symbols:
_libiconv
_libiconv_close
_libiconv_open
make[1]: *** [zsh] Error 1
make: *** [all] Error 1

It also does this on my laptop that has compiled everything since 
4.1.1. without incident.

I can live without the bleeding edge, but thought I should provide the 
feedback...

All the best, and thanks so much for writing the book too.

Bill

William G. Scott

Associate Professor
Department of Chemistry and Biochemistry
and The Center for the Molecular Biology of RNA
Sinsheimer Laboratories
University of California at Santa Cruz
Santa Cruz, California 95064
USA

phone:  +1-831-459-5367 (office)
                +1-831-459-5292 (lab)
fax:         +1-831-4593139  (fax)
url:          http://chemistry.ucsc.edu/~wgscott/


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited. 
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: 4.2.4 failure on MacOS X

[Bart Schaefer]

On Feb 3,  4:15pm, Peter Stephenson wrote:
} Subject: 4.2.4 failure on MacOS X
}
} Just got this... looks like the iconv changes for Cygwin caused other
} problems.

I'd like to know what happens if it's compiled without pcre.  I was a bit
leery when I saw that "-L" option being inserted by pcre-config, and I
wonder if it's not a library ordering issue (e.g. -ldl should come before
-lpcre or some such).

Re: 4.2.4 failure on MacOS X

[Peter Stephenson]

Bart Schaefer wrote:
>> gcc -Wl,-x   -o zsh main.o  `cat stamp-modobjs`   -L/sw/lib -lpcre -ldl 
>> -ltinfo -lm  -lc
>> ld: Undefined symbols:
>> _libiconv
>> _libiconv_close
>> _libiconv_open
> 
> I'd like to know what happens if it's compiled without pcre.  I was a bit
> leery when I saw that "-L" option being inserted by pcre-config, and I
> wonder if it's not a library ordering issue (e.g. -ldl should come before
> -lpcre or some such).

Could be similar, but I don't think it's quite that.  I can see libiconv
in /sw/lib on ppc-sx2.cf.sourceforge.net, but there's no pcre there.
-liconv should presumably be present to get it to link properly; the
missing symbols do seem to be there.  It's possible the pcre bit is
somehow getting rid of -liconv.  I don't see how that could happen,
however.  The line output into configure is simply

if test x$enable_pcre = xyes; then
  LIBS="`pcre-config --libs` $LIBS"
fi

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited. 
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: 4.2.4 failure on MacOS X

[Clint Adams]

> Could be similar, but I don't think it's quite that.  I can see libiconv
> in /sw/lib on ppc-sx2.cf.sourceforge.net, but there's no pcre there.
> -liconv should presumably be present to get it to link properly; the

Be careful, there are at least three iconv's for MacOS X:
- GNU iconv, which Fink would have installed into /sw/lib
- maciconv
- Apple's iconv, which is bundled with MacOS X 10.3 and presumably later
  versions.

I think all three dynamic objects share the same name.

Re: 4.2.4 failure on MacOS X

[Peter A. Castro]

On Thu, 3 Feb 2005, Clint Adams wrote:

> > Could be similar, but I don't think it's quite that.  I can see libiconv
> > in /sw/lib on ppc-sx2.cf.sourceforge.net, but there's no pcre there.
> > -liconv should presumably be present to get it to link properly; the
>
> Be careful, there are at least three iconv's for MacOS X:
> - GNU iconv, which Fink would have installed into /sw/lib
> - maciconv
> - Apple's iconv, which is bundled with MacOS X 10.3 and presumably later
>   versions.

But which one is the correct one to use?  Are they all compatable with
each other and the compiler/runtime being use to build zsh?  Do they all
have an iconv.h header (and if so, how/where)?  I think a little better
detection in configure might be appropriate here, but without a Mac OS-X
environment it's difficult to discern this.

Perhaps it would be good for configure to #undef HAVE_ICONV_H if the
library isn't found?

> I think all three dynamic objects share the same name.

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: 4.2.4 failure on MacOS X

[Peter Stephenson]

> gcc -Wl,-x   -o zsh main.o  `cat stamp-modobjs`   -L/sw/lib -lpcre -ldl 
> -ltinfo -lm  -lc
> ld: Undefined symbols:
> _libiconv
> _libiconv_close
> _libiconv_open

Another possibility:  this error doesn't show the headers, and we now
attempt to compile in the iconv stuff if the headers only were found:

#   if defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV)

Peter, are the tests for HAVE_ICONV_H really necessary on Cygwin?
Shouldn't HAVE_LIBICONV be defined from the test you added?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited. 
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: 4.2.4 failure on MacOS X

[Peter A. Castro]

On Thu, 3 Feb 2005, Peter Stephenson wrote:

> > gcc -Wl,-x   -o zsh main.o  `cat stamp-modobjs`   -L/sw/lib -lpcre -ldl
> > -ltinfo -lm  -lc
> > ld: Undefined symbols:
> > _libiconv
> > _libiconv_close
> > _libiconv_open
>
> Another possibility:  this error doesn't show the headers, and we now
> attempt to compile in the iconv stuff if the headers only were found:
>
> #   if defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV)
>
> Peter, are the tests for HAVE_ICONV_H really necessary on Cygwin?
> Shouldn't HAVE_LIBICONV be defined from the test you added?

Not really, but it did make sense at the time.  You can't compile without
the header, and you can't link without the library, so both must be
present in some form or another.  It's assumed that if the header is
present the function is available.  The question is what library contains
it?  Under Cygwin, the header was available, but the detection of the
library had to be change because the real function name was 'libiconv',
not 'iconv'.  It's possible for iconv to be contained in a different
library under a different name, so perhaps configure should search a few
more places to find in (maybe using the AC_SEARCH_LIBS macro)?  Can
someone who's got a Mac OS-X environment determine what libraries contain
iconv (and where)?  Or is this a matter of the header exists but the
function doesn't?  I'm not sure how one would safe guard against this
without having some really ugly #if statements, or have it as a configure
option.

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: 4.2.4 failure on MacOS X

[Motoi Washida]

I also failed to build zsh on Mac OS X 10.3.7.

I think this is because configure can't find iconv(), because iconv() 
is defined as libiconv() in /usr/include/iconv.h and the configure 
script checks iconv() without using the header file.

I modified configure.ac a bit and seems to work. Here is the patch.

--
Motoi Washida



Index: configure.ac
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.ac,v
retrieving revision 1.25
diff -d -u -r1.25 configure.ac
--- configure.ac	1 Feb 2005 10:53:10 -0000	1.25
+++ configure.ac	3 Feb 2005 18:42:05 -0000
@@ -729,10 +729,11 @@

  AC_CHECK_LIB(iconv, iconv)

-if test "$host_os" = cygwin; then
-dnl cygwin iconv() is really libiconv()
-AC_CHECK_LIB(iconv, libiconv)
-fi
+case "$host_os" in
+  cygwin | darwin*)
+    dnl cygwin iconv() is really libiconv()
+    AC_CHECK_LIB(iconv, libiconv) ;;
+esac

  if test x$enable_pcre = xyes; then
  dnl pcre-config should probably be employed here

Re: 4.2.4 failure on MacOS X

[Peter Stephenson]

Motoi Washida wrote:
> I also failed to build zsh on Mac OS X 10.3.7.
> 
> I think this is because configure can't find iconv(), because iconv() 
> is defined as libiconv() in /usr/include/iconv.h and the configure 
> script checks iconv() without using the header file.
> 
> I modified configure.ac a bit and seems to work. Here is the patch.

Thanks, I've committed this.

I'm a little worried that other systems are going to have the same
problem, however.  Shouldn't it be safe always to test for libiconv as
well as iconv?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited. 
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: 4.2.4 failure on MacOS X

[Peter A. Castro]

On Fri, 4 Feb 2005, Motoi Washida wrote:

> I also failed to build zsh on Mac OS X 10.3.7.
>
> I think this is because configure can't find iconv(), because iconv()
> is defined as libiconv() in /usr/include/iconv.h and the configure
> script checks iconv() without using the header file.
>
> I modified configure.ac a bit and seems to work. Here is the patch.

Excellent!  It seems Darwin and Cygwin share a similar implementation.
Maybe it can simply be made generic? :

AC_CHECK_LIB(iconv, iconv)
AC_CHECK_LIB(iconv, libiconv)

Presumably it's unlikely that both iconv() and libiconv() would exist?

FWIW, I did hack an iconv test which #include the header, if detected,
but this started to get more complicated than it was worth and opt'ed for
simply looking for the real symbol name.

> --
> Motoi Washida
>
>
>
> Index: configure.ac
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/configure.ac,v
> retrieving revision 1.25
> diff -d -u -r1.25 configure.ac
> --- configure.ac	1 Feb 2005 10:53:10 -0000	1.25
> +++ configure.ac	3 Feb 2005 18:42:05 -0000
> @@ -729,10 +729,11 @@
>
>   AC_CHECK_LIB(iconv, iconv)
>
> -if test "$host_os" = cygwin; then
> -dnl cygwin iconv() is really libiconv()
> -AC_CHECK_LIB(iconv, libiconv)
> -fi
> +case "$host_os" in
> +  cygwin | darwin*)
> +    dnl cygwin iconv() is really libiconv()
> +    AC_CHECK_LIB(iconv, libiconv) ;;
> +esac
>
>   if test x$enable_pcre = xyes; then
>   dnl pcre-config should probably be employed here

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood