all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]
@ 2006-03-17 16:30 Richard Stallman
  2006-03-19 15:14 ` Chong Yidong
  0 siblings, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2006-03-17 16:30 UTC (permalink / raw)


Would someone please investigate this, then ack?

------- Start of forwarded message -------
From: "Bauer, Christoph" <Christoph.Bauer@lms-gmbh.de>
To: bug-gnu-emacs@gnu.org
Date: Thu, 16 Mar 2006 16:35:16 +0100
MIME-Version: 1.0
Content-Type: text/plain
Subject: HP-UX: link error

Hi,

on HP-UX I got this error (latest CVS version of emacs).

<long gcc line to link emacs...>
/usr/ccs/bin/ld: Duplicate symbol "append_glyph" in files xdisp.o and term.o
/usr/ccs/bin/ld: Duplicate symbol "produce_stretch_glyph" in files xdisp.o
and term.o
/usr/ccs/bin/ld: Found 2 duplicate symbol(s)
collect2: ld returned 1 exit status

Thanks,
Christoph Bauer



_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]
@ 2006-03-20 16:29 Bauer, Christoph
  2006-03-21 19:22 ` Richard Stallman
  2006-03-21 19:23 ` Richard Stallman
  0 siblings, 2 replies; 18+ messages in thread
From: Bauer, Christoph @ 2006-03-20 16:29 UTC (permalink / raw)
  Cc: emacs-devel


>     > on HP-UX I got this error (latest CVS version of emacs).
>     >
>     > <long gcc line to link emacs...>
>     > /usr/ccs/bin/ld: Duplicate symbol "append_glyph" in files xdisp.o
> and term.o
> 
> I think I see the cause of this.  There is a static function called
> append_glyph defined in xdisp.o.  Apparently that version of GCC
> compiles it in a way that isn't static, effectively producing
> two global definitions of append_glyph.
> 
> I think that is a bug in the compiler and/or linker.  However, I
> wonder why we do this confusing thing in Emacs.  Couldn't we rename
> the function append_glyph that is defined and used in xdisp.c?
> If we rename it to store_next_glyph, does that fix that bug?
> 
> Likewise, we could rename produce_stretch_glyph in xdisp.c
> to generate_stretch_glyph.
> 
> 
> Christoph, could you try that?

I renamed - as you suggested - append_glyph to store_next_glyph and
produce_stretch_glyph to generate_stretch_glyph in xdisp.c and tried to
build with the original cc and gcc.

The linker error is gone for both compilers. With gcc 
make bootstrap and make install succeeded. emacs could
be started.

cc fails with this error in lib-src:

cc -DHAVE_CONFIG_H    -I. -I../src -I/T/tools/unix/build/emacs/emacs/lib-src
-I/T/tools/unix/build/emacs/emacs/lib-src/../src   -g
/T/tools/unix/build/emacs/emacs/lib-src/fakemail.c -l:libdld.sl      -o
fakemail
cpp: "/T/tools/unix/build/emacs/emacs/lib-src/../src/s/hpux9.h", line 63:
warning 2001: Redefinition of macro HAVE_PSTAT_GETDYNAMIC.
cc: "/usr/include/sys/_mbstate_t.h", line 11: error 1000: Unexpected symbol:
"int".
cc: "/usr/include/stdlib.h", line 117: warning 573: Parameter list is
inconsistent for "getenv".
cc: "/T/tools/unix/build/emacs/emacs/lib-src/fakemail.c", line 140: warning
573: Parameter list is inconsistent for "popen".
cc: "/T/tools/unix/build/emacs/emacs/lib-src/fakemail.c", line 141: warning
573: Parameter list is inconsistent for "fclose".
cc: "/T/tools/unix/build/emacs/emacs/lib-src/fakemail.c", line 141: warning
573: Parameter list is inconsistent for "pclose".
make: *** [fakemail] Error 1

Of course I'm happy with the gcc-build :-)

Thanks for the help,
Christoph

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]
@ 2006-03-23  9:47 Christoph Bauer
  2006-03-23 23:09 ` Richard Stallman
  0 siblings, 1 reply; 18+ messages in thread
From: Christoph Bauer @ 2006-03-23  9:47 UTC (permalink / raw)
  Cc: cyd, emacs-devel

> 
> It seems that the configure test for mbstate_t is giving a confusing
> result.  From what you say, it expects wchar.h to define mbstate_t
> but that does not occur.
> 
> Maybe that is a bug in wchar.h on your system.  Is it?

mbstate_t is defined in wchar.h if _INCLUDE__STDC_A1_SOURCE is defined. 

With
$ CFLAGS="-D_INCLUDE__STDC_A1_SOURCE" ../configure 
the unchanged configure is able to find mbstate_t. 
(-> src/config.h is ok).

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]
@ 2006-03-23 11:34 Christoph Bauer
  0 siblings, 0 replies; 18+ messages in thread
From: Christoph Bauer @ 2006-03-23 11:34 UTC (permalink / raw)
  Cc: cyd, rms, emacs-devel



Hi,

> Ken, Richard, Christoph,
> 
> Sorry, but I just reverted the patch to xdisp.c and made a different
> patch to term.c.  So Christoph, I would appreciate if you could test
> compilation on HP-UX again.
> 

it works fine again. I did the build in an empty directory
with native cc and the latest cvs version. configure runs with 
CFLAGS="-D_INCLUDE__STDC_A1_SOURCE -O". I _don't_ have to define
MULTIBYTE_IS_FORMAT_SAFE or fix src/config.h.

So a patch for remaining HP-UX problems could be:

diff -r1.406 configure.in
613a614
>     CFLAGS="-D_INCLUDE__STDC_A1_SOURCE $CFLAGS"

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]
@ 2006-03-23 11:51 Christoph Bauer
  2006-03-23 23:09 ` Richard Stallman
  0 siblings, 1 reply; 18+ messages in thread
From: Christoph Bauer @ 2006-03-23 11:51 UTC (permalink / raw)
  Cc: cyd, emacs-devel

> 
>     So <sys/_mbstate_t.h> is not included (_LIBC in not defined).
>     When I define MULTIBYTE_IS_FORMAT_SAFE in config.h, the build
>     succeeds.

This was just a stupid test. As formerly written with  
-D_INCLUDE__STDC_A1_SOURCE the definition of MULTIBYTE_IS_FORMAT_SAFE
isn't necessary. 
> 
> That does not necessarily mean it is correct to define that
> symbol.  Here's the explanation of it:
> 
>     /* Do multibyte processing if multibytes are supported, unless
>        multibyte sequences are safe in formats.  Multibyte sequences are
>        safe if they cannot contain byte sequences that look like format
>        conversion specifications.  The GNU C Library uses UTF8 multibyte
>        encoding, which is safe for formats, but strftime.c can be used
>        with other C libraries that use unsafe encodings.  */
>     #define DO_MULTIBYTE (HAVE_MBLEN && ! MULTIBYTE_IS_FORMAT_SAFE)
> 
> So, are multibyte sequences safe on your system?

man page of printf(3S) says:

Locale
      The LC_CTYPE category affects the following features:

           +  Plain characters within format strings are interpreted as
              single byte and/or multibyte characters.

           +  Field width is given in terms of bytes.  As characters are
              placed on the output stream, they are interpreted as single
              byte or multibyte characters and the field width is
              decremented by the length of the character.

           +  Precision is given in terms of bytes.  As characters are
              placed on the output stream, they are interpreted as single
              byte or multibyte characters and the precision is decremented
              by the length of the character.

           +  The return value is given in terms of bytes.  As characters
              are placed on the output stream, they are interpreted as
              single byte or multibyte characters and the byte count that
              makes up the return value is incremented by the length of the
              character.

      The LC_NUMERIC category determines the radix character used to print
      floating-point numbers, and the thousands' grouping characters if the
      grouping flag ' is on.

    International Code Set Support
      Single byte character code sets are supported.  Multibyte character
      code sets are also supported as described in the LC_CTYPE category
      above.

So it depends on LC_CTYPE.

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]
@ 2006-03-24  8:47 Christoph Bauer
  0 siblings, 0 replies; 18+ messages in thread
From: Christoph Bauer @ 2006-03-24  8:47 UTC (permalink / raw)
  Cc: cyd, emacs-devel

>     mbstate_t is defined in wchar.h if 
> _INCLUDE__STDC_A1_SOURCE is defined. 
> 
> Should Emacs be defining that macro?
> 

 It would be convenient when configure detects, that
the flag -D_INCLUDE__STDC_A1_SOURCE is necessary to build with
HP-UX cc. In configure.in this could be done in
the "hppa*-hp-hpux1[1-9]*" case [1] by

 CFLAGS="-D_INCLUDE__STDC_A1_SOURCE $CFLAGS"

Otherwise a note in INSTALL for HP-UX would be nice.


[1] Because of lack of older HP machines I cannot check 
the cases for HP-UX 7-10.

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]
@ 2006-03-27  9:01 Christoph Bauer
  0 siblings, 0 replies; 18+ messages in thread
From: Christoph Bauer @ 2006-03-27  9:01 UTC (permalink / raw)
  Cc: cyd, Christoph Bauer, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

>     Yes. 
> 
> Can you suggest a patch to configure.in or to the m/*.h or 
> s/*.h file that will do this?

The patch is attached.

My test machine is: 
$ uname -a
HP-UX snoopy B.11.11 U 9000/785 unknown unknown HP-UX


[-- Attachment #2: hpux.patch --]
[-- Type: application/octet-stream, Size: 359 bytes --]

diff -c -r1.406 configure.in
*** configure.in        14 Feb 2006 15:32:49 -0000      1.406
--- configure.in        27 Mar 2006 08:51:21 -0000
***************
*** 611,616 ****
--- 611,617 ----
    ;;
    hppa*-hp-hpux1[1-9]* )
      machine=hp800 opsys=hpux11
+     CFLAGS="-D_INCLUDE__STDC_A1_SOURCE $CFLAGS"
    ;;
  
    hppa*-*-linux-gnu* )


[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2006-03-27  9:01 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-17 16:30 [Christoph.Bauer@lms-gmbh.de: HP-UX: link error] Richard Stallman
2006-03-19 15:14 ` Chong Yidong
2006-03-19 18:09   ` Sascha Wilde
2006-03-20 15:05   ` Richard Stallman
2006-03-21  6:19     ` Ken Raeburn
2006-03-21 22:29       ` Richard Stallman
2006-03-22  5:08         ` Ken Raeburn
2006-03-22 23:01           ` Kim F. Storm
  -- strict thread matches above, loose matches on Subject: below --
2006-03-20 16:29 Bauer, Christoph
2006-03-21 19:22 ` Richard Stallman
2006-03-21 19:23 ` Richard Stallman
2006-03-23  9:47 Christoph Bauer
2006-03-23 23:09 ` Richard Stallman
2006-03-23 11:34 Christoph Bauer
2006-03-23 11:51 Christoph Bauer
2006-03-23 23:09 ` Richard Stallman
2006-03-24  8:47 Christoph Bauer
2006-03-27  9:01 Christoph Bauer

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.