Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[John David Anglin]

> The underlying *object file format* can't handle weak symbols.  Any attempt
> to use them will ultimately fail.

I wasn't absolutely convinced of that.

> Looks like they (HP) are using aborted code -- we tried to make SOM
> secondary definitions masquerade as weak symbols, but in the end it won't
> work due to limitations of secondary definitions.  Trust me, if they're
> emitting .weak for SOM, it's going to break -- it's just a matter of time.

I thought the major issue was we weren't providing a primary symbol
definition for the secondary.  The primary symbol has to have the same
name as the secondary with '_' prefixed.  Maybe gas just needed a fix
to do this?

I recall we also had some trouble with long symbols using HP nm but
I thought that was fixable with the correct options.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Jeff Law]

 In message < 200208222208.g7MM8DYV007102@hiauly1.hia.nrc.ca >, "John David 
Anglin" writes:
 >> Looks like they (HP) are using aborted code -- we tried to make SOM
 >> secondary definitions masquerade as weak symbols, but in the end it won't
 >> work due to limitations of secondary definitions.  Trust me, if they're
 >> emitting .weak for SOM, it's going to break -- it's just a matter of time.
 >
 >I thought the major issue was we weren't providing a primary symbol
 >definition for the secondary.  The primary symbol has to have the same
 >name as the secondary with '_' prefixed.  Maybe gas just needed a fix
 >to do this?
But the primary symbol had to be a normal symbol with the underscore 
prefix *and* with external scope.  The external scope restriction
is what killed using secondary definitions to emulate weak definitions.

jeff

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[John David Anglin]

> But the primary symbol had to be a normal symbol with the underscore 
> prefix *and* with external scope.  The external scope restriction
> is what killed using secondary definitions to emulate weak definitions.

It's not obvious that the primary needs to be external.  I am looking
at map_secondary_to_primary in fixups.c.  If it needs to be external,
could it be hidden?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Jeff Law]

In message < 200208222245.g7MMjAXl007183@hiauly1.hia.nrc.ca >, "John David Anglin
" writes:
 >> But the primary symbol had to be a normal symbol with the underscore 
 >> prefix *and* with external scope.  The external scope restriction
 >> is what killed using secondary definitions to emulate weak definitions.
 >
 >It's not obvious that the primary needs to be external.  I am looking
 >at map_secondary_to_primary in fixups.c.  If it needs to be external,
 >could it be hidden?
I hadn't thought about trying to tweak the hidden bit for the primary.
It's definitely worth a try -- the lack of weak symbol support is a major
problem on this platform so it's worth some effort to try and make
secondary definitions act like weak symbols.

Jeff

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[John David Anglin]

> I hadn't thought about trying to tweak the hidden bit for the primary.
> It's definitely worth a try -- the lack of weak symbol support is a major
> problem on this platform so it's worth some effort to try and make
> secondary definitions act like weak symbols.

Ok, I try it.  Didn't want to run down a track that already had been
explored.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Albert Chin]

On Thu, Aug 22, 2002 at 05:38:56PM -0600, Jeff Law wrote:
> In message < 200208222245.g7MMjAXl007183@hiauly1.hia.nrc.ca >, "John David Anglin
> " writes:
>  >> But the primary symbol had to be a normal symbol with the underscore 
>  >> prefix *and* with external scope.  The external scope restriction
>  >> is what killed using secondary definitions to emulate weak definitions.
>  >
>  >It's not obvious that the primary needs to be external.  I am looking
>  >at map_secondary_to_primary in fixups.c.  If it needs to be external,
>  >could it be hidden?
> I hadn't thought about trying to tweak the hidden bit for the primary.
> It's definitely worth a try -- the lack of weak symbol support is a major
> problem on this platform so it's worth some effort to try and make
> secondary definitions act like weak symbols.

Does HP-UX handle C++ code with templates well (by "well" I mean as
"well" as on Solaris or Tru64 UNIX or IRIX)? The problems we're
running into have to do with template code.

-- 
albert chin (china@thewrittenword.com)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Jeff Law]

In message < 20020823073245.A35095@oolong.il.thewrittenword.com >, Albert Chin wr
ites:
 >On Thu, Aug 22, 2002 at 05:38:56PM -0600, Jeff Law wrote:
 >> In message < 200208222245.g7MMjAXl007183@hiauly1.hia.nrc.ca >, "John David An
 >glin
 >> " writes:
 >>  >> But the primary symbol had to be a normal symbol with the underscore 
 >>  >> prefix *and* with external scope.  The external scope restriction
 >>  >> is what killed using secondary definitions to emulate weak definitions.
 >>  >
 >>  >It's not obvious that the primary needs to be external.  I am looking
 >>  >at map_secondary_to_primary in fixups.c.  If it needs to be external,
 >>  >could it be hidden?
 >> I hadn't thought about trying to tweak the hidden bit for the primary.
 >> It's definitely worth a try -- the lack of weak symbol support is a major
 >> problem on this platform so it's worth some effort to try and make
 >> secondary definitions act like weak symbols.
 >
 >Does HP-UX handle C++ code with templates well (by "well" I mean as
 >"well" as on Solaris or Tru64 UNIX or IRIX)? The problems we're
 >running into have to do with template code.
Certainly not as well as Solaris or Linux -- the lack of weak symbols means
you get a lot of duplicate function instantiations, so the executables are
much larger and don't exhibit good locality. 

jeff

Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Albert Chin]

I configured and built GCC 3.2 on hppa2.0w-hp-hpux11.11:
  $ CC="cc -Ae +DAportable" ../configure --with-gnu-as \
  --with-included-gettext --enable-shared

I then tried to build LyX 1.2.0, a C++ application and received errors
about unresolved symbols in the final link stage:
  g++ -O2 -march=1.1 [.o files] mathed/.libs/libmathed.a
  insets/.libs/libinsets.a frontends/.libs/libfrontends.a -lforms -lXpm
  graphics/.libs/libgraphics.a support/.libs/libsupport.a
  ../sigc++/.libs/libsigc.a ../intl/libintl.a -lSM -lICE -lc -lm
  -L/usr/lib/X11R6 -lX11
  /usr/ccs/bin/ld: Unsatisfied symbols:
     typeinfo name for MathStackrelInset(first referenced in
mathed/.libs/libmathed.a(formulabase.o)) (data)
     ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
(first referenced in frontends/.libs/libfrontends.a(Alert.o)) (code)
     typeinfo name for InsetError(first referenced in
insets/.libs/libinsets.a(inset.o)) (data)
     typeinfo name for InsetParent(first referenced in
insets/.libs/libinsets.a(inset.o)) (data)
  ...

$ cd /opt/build/lyx-1.2.0/src
$ nm -C libmathed.a | grep MathStackrelInset
         U MathStackrelInset::MathStackrelInset()
...
00000000 T MathStackrelInset::MathStackrelInset()
00000000 T MathStackrelInset::MathStackrelInset()
00000000 t MathStackrelInset::~MathStackrelInset()
00000000 t MathStackrelInset::~MathStackrelInset()
00000000 T MathStackrelInset::draw(Painter&, int, int) const
00000000 T MathStackrelInset::clone() const
00000000 T MathStackrelInset::write(WriteStream&) const
00000000 T MathStackrelInset::metrics(MathMetricsInfo const&) const
00000000 T MathStackrelInset::normalize(NormalStream&) const
4000018c D typeinfo for MathStackrelInset
         U typeinfo name for MathStackrelInset
40000040 D vtable for MathStackrelInset
$ nm -C libfrontends.a | grep updateSlot | grep InsetGraphicsParams
         U ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
00000000 t ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)

The 'nm' above is from GNU binutils. The HP 'nm' doesn't demangle the
C++ symbol names correctly as its -C option works only with ELF
objects.

Did I build GCC wrong? I have similar problems building another C++
application, Octave.

-- 
albert chin (china@thewrittenword.com)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Albert Chin]

On Thu, Aug 22, 2002 at 07:31:07AM -0500, Albert Chin wrote:
> ...
>
> $ nm -C libfrontends.a | grep updateSlot | grep InsetGraphicsParams
>          U ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
> 00000000 t ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)

FYI, I compiled against binutils 2.11.2. I just tried binutils 2.13
with the same result. The problem is the 't' above, which is local.
With the HP gcc-3.2-prerelease, I get:
  $ nm -C ControlGraphics.o | grep updateSlot | grep InsetGraphicsParams
  00000000 W ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
  00000000 W ControlInset<InsetGraphics, InsetGraphicsParams>::update()
  $ /usr/local/bin/g++ -v
  Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux11.00/3.2/specs
  Configured with: ../gcc/configure --enable-languages=c,c++
  --host=hppa1.1-hp-hpux11.00 --target=hppa1.1-hp-hpux11.00
  --with-ld=/usr/ccs/bin/ld --with-gnu-as --enable-libstdcxx-v3
  --disable-checking
  Thread model: single
  gcc version 3.2 20020708 (experimental)

The 'W' WEAK reference matches what I get on Solaris. So, why does my
GCC build return 't', not 'W'?

-- 
albert chin (china@thewrittenword.com)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[John Levon]

On Thu, Aug 22, 2002 at 11:29:47AM -0500, Albert Chin wrote:

> > $ nm -C libfrontends.a | grep updateSlot | grep InsetGraphicsParams
> >          U ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
> > 00000000 t ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
> 
> The 'W' WEAK reference matches what I get on Solaris. So, why does my
> GCC build return 't', not 'W'?

I can only assume this is a toolchain bug. There's no reason this should
be a local symbol only ('t')

If I had diskspace I'd download 3.2 and have a go myself

regards
john
-- 
"Way back at the beginning of time around 1970 the first man page was
 handed down from on high. Every one since is an edited copy."
	- John Hasler <john@dhh.gt.org>

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Albert Chin]

On Thu, Aug 22, 2002 at 05:34:38PM +0100, John Levon wrote:
> On Thu, Aug 22, 2002 at 11:29:47AM -0500, Albert Chin wrote:
> 
> > > $ nm -C libfrontends.a | grep updateSlot | grep InsetGraphicsParams
> > >          U ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
> > > 00000000 t ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(bool)
> > 
> > The 'W' WEAK reference matches what I get on Solaris. So, why does my
> > GCC build return 't', not 'W'?
> 
> I can only assume this is a toolchain bug. There's no reason this should
> be a local symbol only ('t')
> 
> If I had diskspace I'd download 3.2 and have a go myself

What's odd is that the 3.2-prerelease provided by HP works fine. I
don't necessarily think binutils is the problem. I replaced the 'as' I
built with the one provided in their package and have the same
problem. So, GCC must be emitting the 't'.

(HP 3.2-prerelease)
$ g++ -v
Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux11.00/3.2/specs
Configured with: ../gcc/configure --enable-languages=c,c++
--host=hppa1.1-hp-hpux11.00 --target=hppa1.1-hp-hpux11.00
--with-ld=/usr/ccs/bin/ld --with-gnu-as --enable-libstdcxx-v3
--disable-checking
Thread model: single
gcc version 3.2 20020708 (experimental)

(My 3.2 release)
Reading specs from /opt/TWWfsw/gcc32/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.2/specs
Configured with: ../configure --with-gnu-as
--with-as=/opt/TWWfsw/gcc32/hppa2.0w-hp-hpux11.11/bin/as
--with-included-gettext --enable-shared --prefix=/opt/TWWfsw/gcc32
--with-local-prefix=/opt/TWWfsw/gcc32
Thread model: single
gcc version 3.2 (TWW)

I rebuild the offending source with -s and compared the .s files from
both compilers. I get lots of:
-       .weak   _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
-       .EXPORT _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+       .PARAM _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR

-- 
albert chin (china@thewrittenword.com)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Jeff Law]

In message < 20020822114834.B9686@oolong.il.thewrittenword.com >, Albert Chin wri
tes:
 >What's odd is that the 3.2-prerelease provided by HP works fine. I
 >don't necessarily think binutils is the problem. I replaced the 'as' I
 >built with the one provided in their package and have the same
 >problem. So, GCC must be emitting the 't'.
The underlying *object file format* can't handle weak symbols.  Any attempt
to use them will ultimately fail.


[ ... ]
 >(HP 3.2-prerelease)
 >$ g++ -v
 >Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux11.00/3.2/specs
 >Configured with: ../gcc/configure --enable-languages=c,c++
 >--host=hppa1.1-hp-hpux11.00 --target=hppa1.1-hp-hpux11.00
 >--with-ld=/usr/ccs/bin/ld --with-gnu-as --enable-libstdcxx-v3
 >--disable-checking
 >
 >I rebuild the offending source with -s and compared the .s files from
 >both compilers. I get lots of:
 >-       .weak   _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
 >-       .EXPORT _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_,ENTRY,
 >PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
 >+       .PARAM _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_,PRIV_LE
 >V=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
Looks like they (HP) are using aborted code -- we tried to make SOM
secondary definitions masquerade as weak symbols, but in the end it won't
work due to limitations of secondary definitions.  Trust me, if they're
emitting .weak for SOM, it's going to break -- it's just a matter of time.

Of course, the HP provided binaries for GNU tools have always been broken in
various ways -- I strongly recommend against using them.  

jeff

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Albert Chin]

On Thu, Aug 22, 2002 at 01:17:07PM -0600, Jeff Law wrote:
> In message < 20020822114834.B9686@oolong.il.thewrittenword.com >, Albert Chin wri
> tes:
>  >What's odd is that the 3.2-prerelease provided by HP works fine. I
>  >don't necessarily think binutils is the problem. I replaced the 'as' I
>  >built with the one provided in their package and have the same
>  >problem. So, GCC must be emitting the 't'.
> The underlying *object file format* can't handle weak symbols.  Any attempt
> to use them will ultimately fail.

Yep, they indeeded ultimately failed.

-- 
albert chin (china@thewrittenword.com)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Jeff Law]

In message < 20020822112947.A9686@oolong.il.thewrittenword.com >, Albert Chin wri
tes:
 >On Thu, Aug 22, 2002 at 07:31:07AM -0500, Albert Chin wrote:
 >> ...
 >>
 >> $ nm -C libfrontends.a | grep updateSlot | grep InsetGraphicsParams
 >>          U ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(boo
 >l)
 >> 00000000 t ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(boo
 >l)
 >
 >FYI, I compiled against binutils 2.11.2. I just tried binutils 2.13
 >with the same result. The problem is the 't' above, which is local.
 >With the HP gcc-3.2-prerelease, I get:
 >  $ nm -C ControlGraphics.o | grep updateSlot | grep InsetGraphicsParams
 >  00000000 W ControlInset<InsetGraphics, InsetGraphicsParams>::updateSlot(boo
 >l)
 >  00000000 W ControlInset<InsetGraphics, InsetGraphicsParams>::update()
 >  $ /usr/local/bin/g++ -v
 >  Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux11.00/3.2/specs
 >  Configured with: ../gcc/configure --enable-languages=c,c++
 >  --host=hppa1.1-hp-hpux11.00 --target=hppa1.1-hp-hpux11.00
 >  --with-ld=/usr/ccs/bin/ld --with-gnu-as --enable-libstdcxx-v3
 >  --disable-checking
 >  Thread model: single
 >  gcc version 3.2 20020708 (experimental)
 >
 >The 'W' WEAK reference matches what I get on Solaris. So, why does my
 >GCC build return 't', not 'W'?
Weak symbols are not supported in SOM (HP's object format for 32bit
applications).

jeff

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Albert Chin]

On Thu, Aug 22, 2002 at 10:44:43AM -0600, Jeff Law wrote:
> Weak symbols are not supported in SOM (HP's object format for 32bit
> applications).

Ahh, correct. Any idea why I get 't' and not 'T' for. The offending
code is:
  class ControlGraphics
    : public ControlInset<InsetGraphics, InsetGraphicsParams> {
  public:

  ...

  template <class Inset, class Params>
  void ControlInset<Inset, Params>::updateSlot(bool switched)
  {
    if (switched)
      hide();
    else
      update();
  }

-- 
albert chin (china@thewrittenword.com)

Re: Building LyX 1.2.0 on HP-UX 11.11 with G++ 3.2

[Jeff Law]

In message < 20020822130230.C9686@oolong.il.thewrittenword.com >, Albert Chin wri
tes:
 >On Thu, Aug 22, 2002 at 10:44:43AM -0600, Jeff Law wrote:
 >> Weak symbols are not supported in SOM (HP's object format for 32bit
 >> applications).
 >
 >Ahh, correct. Any idea why I get 't' and not 'T' for. The offending
 >code is:
 >  class ControlGraphics
 >    : public ControlInset<InsetGraphics, InsetGraphicsParams> {
 >  public:
 >
 >  ...
 >
 >  template <class Inset, class Params>
 >  void ControlInset<Inset, Params>::updateSlot(bool switched)
 >  {
 >    if (switched)
 >      hide();
 >    else
 >      update();
 >  }
I'm not a C++ guru, so I don't know what all that means.

I do know that on systems where weak symbols are not supported many things
are instantiated as a local symbol.  You can't instantiate things as globals
or you'll get multiply defined functions.

I don't know if this is what's happening in your code or not.

jeff