[gs-bugs] [Bug 689631] 'make' fails even though 'configure' is OK

[bugs.ghostscript.com-bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=689631

htl10 at users.sourceforge.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME



------- Additional Comments From htl10 at users.sourceforge.net  2008-01-03 16:47 -------
You really do not get it... there is absolutely no need to specify
--with-libiconv, because on linux, glibc provides iconv related functions. 
(libiconv is only needed on system where the system libc is not glibc, 
such as Mac OS X). So the recommended procedure is this:

1) use '--with-libiconv=no', or *not specifying it at all*, and also,
most importantly, do *not* put -liconv nor -I<place>/libiconv/include 
anywhere in LDFLAGS nor CFLAGS nor CXXFLAGS, and just let ghostscript's
configure pick up the iconv functions from within glibc and the system
includes in /usr/include . You should find "/usr/include/iconv.h"
which is part of glibc, and it is *different* from libiconv/iconv.h
for very good reasons which I have already explained.

If you *really* want to be awkward, do this in your very preculiar and 
personal set up:

2) a) use '--with-libiconv=gnu',
   b) put LDFLAGS=-L<someplace>/libiconv -lconv
   c) put CFLAGS=-I<someplace>/libiconv/include and
           CXXFLAGS=-I<someplace>/libiconv/include
  do *all three* of the above, and you may get your own libiconv being used.

------------

Let me summarise this again: you either use glibc includes and link against
glibc (i.e. no action required, do *nothing* unusual like you are trying to
do), or you use libiconv includes and link against libiconv. (i.e. setting
appropriate -I<something> in CFLAGS and appropriate -L<something> and
-l<something> in LDFLAGS). Do *not* try to mix-and-match glibc include headers
with linking against libiconv, or using GNU libiconv headers with glibc.

Your initial problem was because you were using libiconv's iconv.h 
rather than glibc's iconv.h - they are different, and for very good reasons.
 




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.