[Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

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 -------

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Would someone please investigate this, then ack?
>
> From: "Bauer, Christoph" <Christoph.Bauer@lms-gmbh.de>
> Subject: HP-UX: link error
> To: bug-gnu-emacs@gnu.org
>
> 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

Does anyone on this list even use HP-UX?

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Richard Stallman <rms@gnu.org> writes:
>> Would someone please investigate this, then ack?
>>
>> From: "Bauer, Christoph" <Christoph.Bauer@lms-gmbh.de>
>> Subject: HP-UX: link error
>> To: bug-gnu-emacs@gnu.org
>>
>> 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
>
> Does anyone on this list even use HP-UX?

I'm owning an old HP 715 with HP-UX 10.20 -- I'll can give it a try
the next days...

cheers
sascha
-- 
Sascha Wilde

"Unix was the first OS where you could carry the media and system
documentation around in a briefcase. This was fixed in BSD4.2."

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

    > 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?

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Bauer, Christoph]

>     > 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

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Ken Raeburn]

On Mar 20, 2006, at 09:05, Richard Stallman wrote:
>> 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.

src/m/hpux.h has "#define static", and I think all the version- 
specific headers inherit it from there; perhaps that's the cause...  
the comment indicates that everything "static" goes into initialized  
data (which may be just the native compiler, or gcc too, I don't  
know), and emacs doesn't like that, so it's worked around.

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

    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.

Yidong, would you please install that change?

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

    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".

Would you like to debug it and send a patch we can try?

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

    src/m/hpux.h has "#define static", and I think all the version- 
    specific headers inherit it from there; perhaps that's the cause...  

You are probably right.  Anyway, the fix is still the same.
Would you like to install the fix?

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Ken Raeburn]

On Mar 21, 2006, at 16:29, Richard Stallman wrote:
> You are probably right.  Anyway, the fix is still the same.
> Would you like to install the fix?

Done; built and tested on Mac OS X (using X instead of Carbon, of  
course).
Christoph, would you care to update from CVS and try the HP-UX build  
again, just to be sure?

Ken

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Kim F. Storm]

Ken Raeburn <raeburn@raeburn.org> writes:

> On Mar 21, 2006, at 16:29, Richard Stallman wrote:
>> You are probably right.  Anyway, the fix is still the same.
>> Would you like to install the fix?
>
> Done; built and tested on Mac OS X (using X instead of Carbon, of
> course).
> Christoph, would you care to update from CVS and try the HP-UX build
> again, just to be sure?
>
> Ken

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.

The reason for reverting the changes is that changing the names
as suggested by Richard made the code in xdisp.c harder to read and
understand.
  Since the "append_" and "produce_" prefixes are each shared by several
related functions in xdisp.c, changing the name of just one of the
functions from each group makes the code harder to understand; if
those two functions are named differently from the rest of the pack,
it is harder to see the relationship.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Christoph Bauer]

> 
> 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).

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Christoph Bauer]

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"

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Christoph Bauer]

> 
>     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.

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

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

Should Emacs be defining that macro?

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

    >     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. 

Are you saying you think that compiling everything with
-D_INCLUDE__STDC_A1_SOURCE is the correct change?

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Christoph Bauer]

>     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.

Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Christoph Bauer]

[-- 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