Bug 690123 - Failed to build ghostscript version 8.63 on UNIX box
Summary: Failed to build ghostscript version 8.63 on UNIX box
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Build Process (show other bugs)
Version: 8.63
Hardware: Sun SunOS
: P4 normal
Assignee: Ralph Giles
URL:
Keywords:
: 690584 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-10-15 06:39 UTC by Mike Jessen
Modified: 2009-07-18 21:10 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Make file from ./configure run. (25.62 KB, application/octet-stream)
2008-10-15 11:05 UTC, Mike Jessen
Details
Log file from ./configure run. (59.64 KB, text/x-log)
2008-10-15 11:06 UTC, Mike Jessen
Details
Log file from make -f Makefile run. (448.36 KB, text/x-log)
2008-10-15 13:27 UTC, Mike Jessen
Details
diff between rev 8991 and 8992 (1.04 KB, patch)
2008-10-20 10:06 UTC, Alex Cherepanov
Details | Diff
ZIP file with Makefile, logs and scripts. (86.88 KB, application/octet-stream)
2008-10-23 08:54 UTC, Mike Jessen
Details
Details of the latest run of make (v3) (92.25 KB, application/octet-stream)
2008-10-23 11:28 UTC, Mike Jessen
Details
ld.tr (11.99 KB, text/plain)
2008-10-23 13:50 UTC, Mike Jessen
Details
ldt.tr (12.10 KB, text/plain)
2008-10-23 13:51 UTC, Mike Jessen
Details
libiconv_open grep (1.40 KB, text/x-log)
2008-10-27 09:20 UTC, Mike Jessen
Details
/usr/include/*.h grep (file list, nothing returned from grep) (13.99 KB, text/x-log)
2008-10-27 10:51 UTC, Mike Jessen
Details
iconv.h (4.19 KB, text/x-chdr)
2008-10-28 08:45 UTC, Mike Jessen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Jessen 2008-10-15 06:39:49 UTC
Running ./configure generated Makefile without issue.  However, on "make -f
Makefile", the process fails with following error:

ld: fatal: Symbol referencing errors. No output written to ./bin/gs
collect2: ld returned 1 exit status
make: *** [bin/gs] Error 1

System info (uname -a):
SunOS richtestxpp01 5.9 Generic_122300-02 sun4u sparc SUNW,Ultra-60 

Makefile and config.log can be provided if necessary.

Thanks for all your help!
Mike Jessen
Software Developer
Cadmus Communications, a Cenveo company
2905 Byrdhill Road
Richmond, VA  23228
Tel: (804) 261-3091
Fax: (804) 266-2437
jessenm@cadmus.com
www.cenveo.com
Comment 1 Ralph Giles 2008-10-15 10:42:42 UTC
I suppose you'd better attach the Makefile, config.log and make output. There's
not enough in the message you posted to diagnose the problem.
Comment 2 Mike Jessen 2008-10-15 11:05:31 UTC
Created attachment 4509 [details]
Make file from ./configure run.
Comment 3 Mike Jessen 2008-10-15 11:06:19 UTC
Created attachment 4510 [details]
Log file from ./configure run.
Comment 4 Mike Jessen 2008-10-15 11:06:58 UTC
Output from make was not captured, just sent to screen.
Comment 5 Ray Johnston 2008-10-15 11:13:15 UTC
Please capture the output using:

   rm -fr obj bin
   make -f Makefile > make.log 2>&1
Comment 6 Mike Jessen 2008-10-15 13:27:16 UTC
Created attachment 4511 [details]
Log file from make -f Makefile run.
Comment 7 Mike Jessen 2008-10-20 06:50:54 UTC
Any update on this issue?  Should I be using any specific options when running
./configure?  

Thanks!
Mike J.
Comment 8 Alex Cherepanov 2008-10-20 10:06:39 UTC
Created attachment 4520 [details]
diff between rev 8991 and 8992 

This problem is caused by the conflict between GNU headers that redefine
iconv* functions and the native libraries.

Please apply the attached patch and re-generate configure script using
autogen.sh .
Comment 9 Mike Jessen 2008-10-21 07:08:56 UTC
Trying patch now...  Will update BUG on completion (success or fail).
Comment 10 Mike Jessen 2008-10-23 08:54:52 UTC
Created attachment 4534 [details]
ZIP file with Makefile, logs and scripts.

Still failing on make even after patch applied.  Attached zip contains logs,
Makefile and modified scripts as per-patch.

Mike
Comment 11 Ralph Giles 2008-10-23 09:45:44 UTC
Try 'make clean' followed by './autogen.sh' (with any configure options) and
'make' again.

If it still doesn't work after that, please attach your obj/ld.tr and obj/ldt.tr.
Comment 12 Mike Jessen 2008-10-23 11:28:26 UTC
Created attachment 4535 [details]
Details of the latest run of make (v3)

Attached zip contains logs, Makefile and *.tr files for review.  Latest "make"
run still failing.  

Thanks for all your help!
Comment 13 Ralph Giles 2008-10-23 12:19:54 UTC
Huh. It's finding iconv_open() in libc, and not defining USE_LIBICONV_GNU, which
should define LIBCONV_PLUG which is supposed to turn off the iconv->libiconv
name mangling if you have the GNU iconv header around. Yet the mangling is
clearly still happenning.

Can you forward your /usr/include/iconv.h and/or the preprocessor output for
gdevopvp.c?
Comment 14 Mike Jessen 2008-10-23 13:50:50 UTC
Created attachment 4536 [details]
ld.tr
Comment 15 Mike Jessen 2008-10-23 13:51:50 UTC
Created attachment 4537 [details]
ldt.tr

ld.tr and ldt.tr files attached.
Comment 16 Alex Cherepanov 2008-10-24 13:51:36 UTC
Can you grep include files for libiconv_open and check what's going on there ?
Comment 17 Mike Jessen 2008-10-27 09:20:41 UTC
Created attachment 4549 [details]
libiconv_open grep

Is this what you're looking for?
Comment 18 Ralph Giles 2008-10-27 10:21:02 UTC
No. Something in your system headers if changing our iconv_open to
libiconv_open, which prevents us from using the libc call configure detected. We
need to find the section of your system headers where this is happening to
diagnose the problem.

Please run the same grep on /usr/include/*.h, for example.
Comment 19 Mike Jessen 2008-10-27 10:51:35 UTC
Created attachment 4550 [details]
/usr/include/*.h grep (file list, nothing returned from grep)

Nothing was returned from grep:

 grep libiconv_open /usr/include/*.h

...out of 226 *.h files in /usr/include directory (directoyr file list
attaced).
Comment 20 Ralph Giles 2008-10-27 11:00:11 UTC
Well, does your compiler have any other default search paths? Try
/usr/include/*/*.h and /usr/local/include/*.h

or just attach your /usr/include/iconv.h as suggested in #13.
Comment 21 Mike Jessen 2008-10-28 08:45:07 UTC
Created attachment 4553 [details]
iconv.h
Comment 22 Mike Jessen 2008-11-14 10:11:37 UTC
Any update on this issue?
Comment 23 Ralph Giles 2008-11-17 16:51:30 UTC
Ok, I *think* I understand what's happening. Your iconv.h is from gnu iconv, but
it tries to emulate the system iconv, so just including iconv.h you get
iconv_open(). The configure script finds and iconv_open() in the C library and
decides you have a system implementation. But gdevopvp.c defines LIBCONV_PLUG
unless configure notices you have the gnu version, and that makes your gnu
iconv.h mangle iconv_open() to libiconv_open(), which *isn't* in the C library.

So a few things to try, separately:

* Does the build complete without the undefined symbol warnings if you add
-liconv to the EXTRA_LIBS line in the Makefile?

* If you take -liconv back out, but remove the clause:

  /* Set compatibility flag just in case we have GNU iconv.h */
  #ifndef USE_LIBICONV_GNU
  #  define LIBCONV_PLUG
  #endif

before the inclusion of iconv.h in contrib/opvp/gdevopvp.c, does it also work?

* Does it work if you pass --with-libiconv=gnu to ./configure and then rebuild,
forcing it to treat it as the gnu version?

This looks like an unfortunately side effect of a number of unfortunate hacks,
but I do wonder what happened to the header file that declares the iconv_open
function the configure script finds in the C library.
Comment 24 Alex Cherepanov 2008-11-17 20:51:42 UTC
IMHO the effects of the checks are opposite:
GNU iconv.h by default mangles iconv_open() to libiconv_open().
LIBCONV_PLUG prevents the mangling.
LIBCONV_PLUG is defined when the library is not GNU. i.e. iconv_open()
can be found by linker. L

So I don't see any problems with the current code.

I'd start to debug this issue by writing a small program to exercise
preprocessor, compiler, and linker without the make files and
configure script.
Comment 25 Hin-Tak Leung 2009-01-19 20:47:57 UTC
Does any of the options with --with-libiconv=* improve or work around the issue?

Also, it might be possible to workaround the issue by actually installing gnu
libiconv into /usr/local/{include,lib} (which may cause problems with building
other software which expects iconv to be provided by the system libc), or a
private directory with some suitable CFLAGS and LDFLAGS.

Neither of these are ideal...
Comment 26 Mike Jessen 2009-01-20 07:07:18 UTC
Thanks for the continued effort.  I have made no further attempts to install GS
version 8.63.  I was able to succesfully install GS version 8.54 on all
applicable servers.  This "newer" version (was running 6.53) suits my needs.  

Again, thanks to everyone for all their efforts.  Feel free to close this ticket.

Mike
Comment 27 Alex Cherepanov 2009-07-18 21:03:36 UTC
Fix a typo in compile time flag that prevented GNU libiconv to emulate
system libiconv and caused link errors on the systems that use GNU headers
but system libraries.

Index: gs/contrib/opvp/gdevopvp.c
===================================================================
--- gs/contrib/opvp/gdevopvp.c  (revision 9846)
+++ gs/contrib/opvp/gdevopvp.c  (working copy)
@@ -33,7 +33,7 @@

 /* Set compatibility flag just in case we have GNU iconv.h */
 #ifndef USE_LIBICONV_GNU
-#  define LIBCONV_PLUG
+#  define LIBICONV_PLUG
 #endif
 #include <iconv.h>

This patch has been committed as a rev. 9871. Regression testing shows
no differences. By some reason this simple type was surprisingly
difficult to find.

Comment 28 Alex Cherepanov 2009-07-18 21:10:44 UTC
*** Bug 690584 has been marked as a duplicate of this bug. ***