Created attachment 16815 [details]
preproccesed source

the following looks weired for me:

# 31 "/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c" 2
# 1 "../config.h" 1
# 32 "/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c" 2





float
((float)fabs((double)(float)(float x)))
{
  return (float) fabs(x);
}

(In reply to comment #1)
> Created an attachment (id=16815) [edit]
> preproccesed source
> 
> the following looks weired for me:
> 
> # 31 "/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c" 2
> # 1 "../config.h" 1
> # 32 "/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c" 2
> 
> 
> 
> 
> 
> float
> ((float)fabs((double)(float)(float x)))
> {
>   return (float) fabs(x);
> }
> 
> 

And this is caused by the following lines in /usr/include/math.h

#    ifdef _PA_RISC
#      define _FPCLASSIFY(x)     (_IS32(x)?_Fpclassifyf(x)>>1:_Fpclassify(x)>>1)
       extern int _Fpclassify(double);
       extern int _Fpclassifyf(float);
#      ifndef _DISALLOW_MASKING_MACROS
#        define fabsf(x) ((float)fabs((double)(float)(x)))
#      endif
#    else /* __IA64__ */  

This doesn't occur in native builds because:

/* Define to 1 if you have the `fabsf' function. */
#define HAVE_FABSF 1

Created attachment 16999 [details]
libstdc++/config.log

The tests for the mathematical functions are skipped all together.
Does anybody sees why?

Subject: Re:  fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

> The tests for the mathematical functions are skipped all together.
> Does anybody sees why?

It would seem linking tests could be done when build == host.

As far as libmath/stubs.c goes, perhaps the obvious undef should be
added to prevent this problem.

Dave

Build and Host is x86_64-unknown-linux-gnu.

I compared to a cross-build for ia64-unknown-linux-gnu target.
In that case the tests are working.
So, I'm a litlle bit confused.

I may upload the config.log for the ia64-unknown-linux-gnu target.

Created attachment 17035 [details]
add fabsf for hpux10/11


Try this.

Ranier, when cross compiling, link tests cannot always be done. Therefore, libstdc++ hardcodes "found" functions when cross compiling, and discovers "found" functions when building for native. 

The problem with this approach is that the hardcoded list in crossconfig.m4 can become out of date. Thus, the comment in #5 to update this list. I did this, see attached. For HPUX, that is:

  *-hpux*)
    SECTION_FLAGS='-ffunction-sections -fdata-sections'
    AC_SUBST(SECTION_FLAGS)
    GLIBCXX_CHECK_LINKER_FEATURES
    GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT
    AC_DEFINE(HAVE_COPYSIGN)
    AC_DEFINE(HAVE_COPYSIGNF)
    AC_DEFINE(HAVE_FREXPF)
    AC_DEFINE(HAVE_HYPOT)
    case "$target" in
      *-hpux10*)
	AC_DEFINE(HAVE_FINITE)
	AC_DEFINE(HAVE_FINITEF)
	AC_DEFINE(HAVE_ISINF)
	AC_DEFINE(HAVE_ISINFF)
	AC_DEFINE(HAVE_ISNAN)
	AC_DEFINE(HAVE_ISNANF)
	;;


Now from looking on the web, it looks like HPUX 10.20 and HPUX 11.x have fabsf so the attached patch looks correct. However, this is rarely-touched code so perhaps further clean-up is warranted: I'll check in this first part to get the ball rolling.

The current config only defines isinf, etc for 10.20, which seems suspicious to me.

What I would suggest doing is looking at the generated c++config.h file from a native build on hpux11.00, and seeing if HAVE_FINITE to HAVE_ISNANF are defined. If so, move them out of the 10.20 block and into the hpux* generic block. Dave any cleanups here are pre-approved.

Subject: Bug 38384

Author: bkoz
Date: Mon Jan  5 20:50:25 2009
New Revision: 143093

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143093
Log:
2009-01-05  Benjamin Kosnik  <bkoz@redhat.com>

	PR libstdc++/38384
	* crossconfig.m4: Define HAVE_FABSF for hpux crosses.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/crossconfig.m4

(In reply to comment #8)
 
> What I would suggest doing is looking at the generated c++config.h file from a
> native build on hpux11.00, and seeing if HAVE_FINITE to HAVE_ISNANF are
> defined. If so, move them out of the 10.20 block and into the hpux* generic
> block. Dave any cleanups here are pre-approved.
> 

I can't help here, because I don't have access to a functional HP-UX system.

Subject: Re:  fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

> > What I would suggest doing is looking at the generated c++config.h file from a
> > native build on hpux11.00, and seeing if HAVE_FINITE to HAVE_ISNANF are
> > defined. If so, move them out of the 10.20 block and into the hpux* generic
> > block. Dave any cleanups here are pre-approved.
> > 
> 
> I can't help here, because I don't have access to a functional HP-UX system.

At the moment, my HP-UX 11.00 system has a bad hard drive.  I need
to remove it and resetup the /usr/home file system.

Dave

Subject: Re:  fails to build cross gcc for target
	hppa64-hp-hpux11.00 in libstdc++/libmath

On Mon, 05 Jan 2009, bkoz at gcc dot gnu dot org wrote:

> What I would suggest doing is looking at the generated c++config.h file from a
> native build on hpux11.00, and seeing if HAVE_FINITE to HAVE_ISNANF are
> defined. If so, move them out of the 10.20 block and into the hpux* generic
> block. Dave any cleanups here are pre-approved.

Attached of c++config.h files from 11.00 (4.3.1) and 11.11 (4.4.0).

Dave

Created attachment 17040 [details]
c++config.h-11.00

Created attachment 17041 [details]
c++config.h-11.11

Any chance I could get a generated c++config.h from a native HPUX 10.x build as well?

Subject: Re:  fails to build cross gcc for target
	hppa64-hp-hpux11.00 in libstdc++/libmath

On Fri, 09 Jan 2009, bkoz at gcc dot gnu dot org wrote:

> Any chance I could get a generated c++config.h from a native HPUX 10.x build as
> well?

Attached.

Dave

Created attachment 17071 [details]
c++config.h-10.20

Thanks for your help Dave: this should be fixed now. (FWIW, the 10.20 config is correct, or mostly correct.) Still, it's nice to confirm.

Ranier, this should be working now. Can you try to cross-compile as before, but with updated gcc sources? 

Subject: Bug 38384

Author: bkoz
Date: Tue Jan 13 01:49:30 2009
New Revision: 143322

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143322
Log:
2009-01-12  Benjamin Kosnik  <bkoz@redhat.com>

	PR libstdc++/38384
	* crossconfig.m4 (hpux): Update for 10.20, 11, 11.20.
	* configure: Regenerate.

2009-01-12  Benjamin Kosnik  <bkoz@redhat.com>

	* crossconfig.m4 (linux): Add GCC_CHECK_TLS to define _GLIBCXX_HAVE_TLS.
	Use GLIBCXX_CHECK_COMPILER_FEATURES to compute SECTION_FLAGS.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/crossconfig.m4

(In reply to comment #18)
> Ranier, this should be working now. Can you try to cross-compile as before, but
> with updated gcc sources? 
> 

Now it builds, but there are some issues.
Will come back to this next week.

The link step for libstdc++.la gives warnings for failed file format test using a file magic. This is wrong!

The problem results from different output of native file command and the linux file command.
libtool uses the following regex:
"(s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]"
This matches for the native file command output: 
"libm.2:         ELF-64 shared object file - PA-RISC 2.0 (LP64)"
But not for the output of the Linux file command:
"libm.2: ELF 64-bit MSB shared object, PA-RISC 2.0 (LP64) version 1, not stripped"

Any idea how to fix this?
I think in libtool.m4 in the top directory. But I'm lost with regex expressions.

I dont't know if the warnings at the end of this message are a result of this issue or different one. The linker complains about fde encoding in .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr table being created. 
There are a lot.

Rainer

/bin/sh ../libtool --tag CXX --mode=link /SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc -shared-libgcc -B/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc -nostdinc++ -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src/.libs -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/bin/ -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib/ -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/include -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/sys-include -Wl,-O1   -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once  -ffunction-sections -fdata-sections   -o libstdc++.la -rpath /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib -version-info 6:11:0 -Wl,--version-script=libstdc++-symbols.ver -lm  atomic.lo bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo functexcept.lo hash.lo hash_c++0x.lo globals_io.lo hashtable.lo hashtable_c++0x.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo limits_c++0x.lo list.lo debug_list.lo locale.lo locale_init.lo locale_facets.lo localename.lo stdexcept.lo strstream.lo system_error.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo mutex.lo condition_variable.lo chrono.lo thread.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo  parallel_list.lo parallel_settings.lo  ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm 

*** Warning: linker path does not have real file for library -lm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /opt/tec/setup/sys-root/HP-UX/hppa64-hp-hpux11.00/B.11.00/usr/lib/pa20_64/./libm.2

*** Warning: linker path does not have real file for library -lgcc_s.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgcc_s and none of the candidates passed a file format test
*** using a file magic. Last file checked: /opt/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/lib/libgcc_s.so.1
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
libtool: link:  /SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc -shared-libgcc -B/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc -nostdinc++ -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src/.libs -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/bin/ -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib/ -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/include -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/sys-include -shared -nostdlib /SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/crtbeginS.o  .libs/atomic.o .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/functexcept.o .libs/hash.o .libs/hash_c++0x.o .libs/globals_io.o .libs/hashtable.o .libs/hashtable_c++0x.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/limits_c++0x.o .libs/list.o .libs/debug_list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/system_error.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/mutex.o .libs/condition_variable.o .libs/chrono.o .libs/thread.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o .libs/parallel_list.o .libs/parallel_settings.o  -Wl,--whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive  -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src/.libs -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc -L/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/bin -L/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib -L/opt/tec/setup/sys-root/HP-UX/hppa64-hp-hpux11.00/B.11.00/usr/lib/pa20_64 /SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/crtendS.o  -Wl,-O1 -Wl,--version-script=libstdc++-symbols.ver   -Wl,-soname -Wl,libstdc++.sl.6 -o .libs/libstdc++.sl.6.11
/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/bin/hppa64-hp-hpux11.00-ld: fde encoding in .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr table being created.
/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/bin/hppa64-hp-hpux11.00-ld: fde encoding in .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr table being created.
/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/bin/hppa64-hp-hpux11.00-ld: fde encoding in .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr table being created. 

(In reply to comment #21)
> libtool uses the following regex:
> "(s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]"
> This matches for the native file command output: 
> "libm.2:         ELF-64 shared object file - PA-RISC 2.0 (LP64)"
> But not for the output of the Linux file command:
> "libm.2: ELF 64-bit MSB shared object, PA-RISC 2.0 (LP64) version 1, not stripped"

This one matches both:
"(s[0-9][0-9][0-9]|ELF[ -]{1}[0-9][0-9][bit MSB-]*) shared object[, file-]* PA-RISC [0-9].[0-9]"

Will try this!

Rainer

Created attachment 17118 [details]
fix file magic regex for hppa*64*

This patch fixes the file magic regex for hppa*64*.
All dependent files have to be regenerated.

This modified regex allows to detect PA-RISC shared objects with the native HP-UX file command and with the BSD file command as of version 4.21.

Dave, can you try this on a native system?

(In reply to comment #23)
> This patch fixes the file magic regex for hppa*64*.
> All dependent files have to be regenerated.
> 
> This modified regex allows to detect PA-RISC shared objects with the native
> HP-UX file command and with the BSD file command as of version 4.21.

Changes to libtool.m4 should be posted upstream (to the libtool-patches at
gnu.org list) and integrated there first.  For this particular patch, can
you please check the other HP-UX hosts and fix them as well?

Thank you,
Ralf

Subject: Re:  fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

> Created an attachment (id=17118)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17118&action=view)
> fix file magic regex for hppa*64*

This is a change to libtool, so it will have to be accepted by
the libtool project before it can be applied to the gcc files.

> Dave, can you try this on a native system?

I'll try it when my current testing completes.

Dave

(In reply to comment #24)
> (In reply to comment #23)
> > This patch fixes the file magic regex for hppa*64*.
> > All dependent files have to be regenerated.
> > 
> > This modified regex allows to detect PA-RISC shared objects with the native
> > HP-UX file command and with the BSD file command as of version 4.21.
> 
> Changes to libtool.m4 should be posted upstream (to the libtool-patches at
> gnu.org list) and integrated there first.  For this particular patch, can
> you please check the other HP-UX hosts and fix them as well?
> 
> Thank you,
> Ralf
> 

I posted to bug-libtool@gnu.org referencing this discussion.
For the other HP-UX hosts I can say the following.
I don't have a Itanium system around, so I can't do anything.
The entry for the remaining HP-UX hosts doesn't works at all.
I upload a new patch.

Subject: Re:  fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

> Changes to libtool.m4 should be posted upstream (to the libtool-patches at
> gnu.org list) and integrated there first.  For this particular patch, can
> you please check the other HP-UX hosts and fix them as well?

The same probably applies to ia64.  For the 32-bit SOM runtime, there
is only the native linker and dynamic loader.  So, the issue is somewhat
academic.

However, here's the the output of the linux file command on a PA 1.1
SOM shared library:

dave@hiauly6:~$ file libintl.sl.8.1
libintl.sl.8.1: PA-RISC1.1 shared library - not stripped

Assume "1.1" could also be "1.0" or "2.0", depending on compilation
options.

Dave

Created attachment 17119 [details]
fix file magic regex for hppa*64*

updated patch

Created attachment 17120 [details]
fix file magic regex for HP-UX hosts

updated patch for all HP-UX hosts.

(In reply to comment #21)
 
> I dont't know if the warnings at the end of this message are a result of this
> issue or different one. The linker complains about fde encoding in
> .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr table being created. 
> There are a lot.
> 
> /hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/bin/hppa64-hp-hpux11.00-ld:
> fde encoding in .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr
> table being created. 
> 

These warnings about fde encoding survive. What does this mean?
How to fix it?

Rainer

Subject: Re:  fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

> > I dont't know if the warnings at the end of this message are a result of this
> > issue or different one. The linker complains about fde encoding in
> > .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr table being created. 
> > There are a lot.
> > 
> > /hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/bin/hppa64-hp-hpux11.00-ld:
> > fde encoding in .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr
> > table being created. 
> > 
> 
> These warnings about fde encoding survive. What does this mean?
> How to fix it?

Probably, the warning needs to be suppressed.  The warning is correct
in that the encoding currently used contains dynamic relocations
preventing the creation of a .eh_frame_hdr table.  This only applies
to GNU ld.  HP ld doesn't support this.  Functionally, this is
only a performance issue.

Still it would be good if the relocations could be eliminated.  However,
the standard technique using pc-relative encoding doesn't work because
the dynamic linker doesn't maintain a consistent relationship between
text and data for dynamically loaded objects.  It's not possible to
reference text locations from the data segment using pc-relative
offsets.

It may be possible to use segment relative encodings.  I added
some support to gas to do this last summer.  There's still an
issue with the functions to compute the base for these encodings.

There are lots of issues with using GNU ld on HP-UX.  It hasn't
been maintained at more than a basic level for some time.

Dave

(In reply to comment #31)
> 
> Probably, the warning needs to be suppressed.  The warning is correct
> in that the encoding currently used contains dynamic relocations
> preventing the creation of a .eh_frame_hdr table.  This only applies
> to GNU ld.  HP ld doesn't support this.  Functionally, this is
> only a performance issue.
> 
> Still it would be good if the relocations could be eliminated.  However,
> the standard technique using pc-relative encoding doesn't work because
> the dynamic linker doesn't maintain a consistent relationship between
> text and data for dynamically loaded objects.  It's not possible to
> reference text locations from the data segment using pc-relative
> offsets.
> 
> It may be possible to use segment relative encodings.  I added
> some support to gas to do this last summer.  There's still an
> issue with the functions to compute the base for these encodings.
> 
> There are lots of issues with using GNU ld on HP-UX.  It hasn't
> been maintained at more than a basic level for some time.
> 
> Dave
> 

Dave, thank you for the explanation.
Next week I will try to build some functional C++ application.
Then we will see if there are remaining issues.

Rainer

(In reply to comment #32)
> 
> Dave, thank you for the explanation.
> Next week I will try to build some functional C++ application.
> Then we will see if there are remaining issues.
> 
> Rainer
> 

There are some strange symptoms.

I tried to build a simple "Hello, World!" application in 4 variants.
1. C source using gcc
2. C source using gcc, static linking
3. C++ source using g++
4. C++ source using g++, static linking

I will create attachments containing the compile logs.

1. Compilation ok, excecution on the target system ok, but ldd on the target system gives:
ldd: "hello" is not a shared executable.

2. Compilation ok,  execution on the target system gives:
./hello: cannot execute binary file

3. Linking fails!

4. Compilation ok, execution on the target system gives:
./hello: cannot execute binary file

Any idea?

Created attachment 17140 [details]
C compile log

Created attachment 17141 [details]
C compile static log

Created attachment 17142 [details]
C++ compile log

Created attachment 17143 [details]
C++ compile static log

Subject: Re:  fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

> There are some strange symptoms.
> 
> I tried to build a simple "Hello, World!" application in 4 variants.
> 1. C source using gcc
> 2. C source using gcc, static linking
> 3. C++ source using g++
> 4. C++ source using g++, static linking
> 
> I will create attachments containing the compile logs.
> 
> 1. Compilation ok, excecution on the target system ok, but ldd on the target
> system gives:
> ldd: "hello" is not a shared executable.
> 
> 2. Compilation ok,  execution on the target system gives:
> ./hello: cannot execute binary file
> 
> 3. Linking fails!
> 
> 4. Compilation ok, execution on the target system gives:
> ./hello: cannot execute binary file
> 
> Any idea?

Use file, chatr, ldd and readelf commands to check file type and ELF
information.  Compare with native application.

GNU ld doesn't create "static" executables (known problem).  It
can only create dynamic executables.  Typically, problems in launching
dynamic executables are debugged by running the dynamic linker under
gdb.  This is hard here because the dynamic linker is proprietary.

3 is probably a binutils bug.  I haven't tried a native build
using GNU ld for some time.  It used to be good enough to do what
you want.

Dave

Hey all. It looks like the libstdc++ part of this is fixed. Therefore, I am going to slightly edit the subject, un-assign myself, and change the component to target. Although I suppose it could be binutils.

From looking at the log of #3, I would suggest that one thing to try would be to explicitly turn off symbol versioning for libstdc++. It looks like the libstdc++ library is using symbol versioning, which will only make debugging the linking/binutils part of this more complicated. You can do so by configuring with 

--disable-symvers

Subject: Re:  link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

> >From looking at the log of #3, I would suggest that one thing to try would be
> to explicitly turn off symbol versioning for libstdc++. It looks like the
> libstdc++ library is using symbol versioning, which will only make debugging
> the linking/binutils part of this more complicated. You can do so by
> configuring with 
> 
> --disable-symvers

GNU symbol versioning is not supported by the HP-UX dynamic linker, so
this should be off as suggested.

Dave

(In reply to comment #40)
> Subject: Re:  link/execute fails for cross gcc from linux to target
> hppa64-hp-hpux11.00
> > configuring with 
> > 
> > --disable-symvers
> 
> GNU symbol versioning is not supported by the HP-UX dynamic linker, so
> this should be off as suggested.
> 
> Dave
> 

configuring with --disable-symvers --disable-shared solves the problem for now.
So in fact --disable-shared should be sufficient because there's no symbol versioning in archives right?

I think for native builds using the gnu ld it's the same issue. Some hints in the documentation would be useful.

So, configuring with --enable-shared does not work.
The build shared libraries can't be handled by the HP-UX loader.

Thanks to Dave and Benjamin.

Subject: Re:  link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

> configuring with --disable-symvers --disable-shared solves the problem for now.
> So in fact --disable-shared should be sufficient because there's no symbol
> versioning in archives right?
> 
> I think for native builds using the gnu ld it's the same issue. Some hints in
> the documentation would be useful.

I'm thinking configure should disable symvers on hppa*-*-hpux* by default.
I had a patch to do this at one time.

> So, configuring with --enable-shared does not work.
> The build shared libraries can't be handled by the HP-UX loader.

Shared libraries did work at one time, although GNU ld has never worked
very well on this target.

I haven't done anything on this since PR 20939.

Dave

Subject: Bug 38384

Author: bkoz
Date: Thu Jan 22 21:40:23 2009
New Revision: 143576

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143576
Log:
2009-01-22  Benjamin Kosnik  <bkoz@redhat.com>

	PR libstdc++/38384
	* acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Disable symbol versioning
	on HPUX.
	* configure: Regenerate.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/configure

Hey. I couldn't stop myself: since Dave said that HPUX doesn't support symbol versioning, (no way, no how) I have changed libstdc++ configure to reflect this.

:)

Ranier, great to see you got something working. I've changed the summary again to reflect what is now left of this bug. You are correct in that --disable-shared turns off shared library versioning, since versioning only applies to the shared lib.

I believe that this is a documentation-only bug at this point. 

In particular, I think that this documentation page:
http://gcc.gnu.org/install/specific.html#hppa-hp-hpux

Should reflect this discussion. As it stands this:

There are a number of issues to consider in selecting which linker to use with the 64-bit port. The GNU 64-bit linker can only create dynamic binaries. The -static option causes linking with archive libraries but doesn't produce a truly static binary. Dynamic binaries still require final binding by the dynamic loader to resolve a set of dynamic-loader-defined symbols. The default behavior of the HP linker is the same as the GNU linker. However, it can generate true 64-bit static binaries using the +compat option. 

oddly changes:

The GNU 64-bit linker has some issues with shared library support and exceptions. As a result, we only support libgcc in archive format. For similar reasons, dwarf2 unwind and exception support are disabled. The GNU linker also has problems creating binaries with -static. It doesn't provide stubs for internal calls to global functions in shared libraries, so these calls can't be overloaded. 

I can see how people are confused by this. GNU ld appears to not really work with shared or static libs, from the docs. (But maybe just for 64 bit targets?) But experience says it works with static libs, but not shared libs. Something needs to be changed, and this section should be updated with the latest status and best practice (which appears to be GNU as, HPUX ld).  (FWIW, it looks like shared libgcc is being created on this target now with GNU ld or else this alone would turn off symbol versioning.) Some love here by people in the know would be helpful to all.

I leave the edits to the target maintainer.

Subject: Re:  shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

> Hey. I couldn't stop myself: since Dave said that HPUX doesn't support symbol
> versioning, (no way, no how) I have changed libstdc++ configure to reflect
> this.
> 
> :)
> 
> Ranier, great to see you got something working. I've changed the summary again
> to reflect what is now left of this bug. You are correct in that
> --disable-shared turns off shared library versioning, since versioning only
> applies to the shared lib.
> 
> I believe that this is a documentation-only bug at this point. 
> 
> In particular, I think that this documentation page:
> http://gcc.gnu.org/install/specific.html#hppa-hp-hpux
> 
> Should reflect this discussion. As it stands this:
> 
> There are a number of issues to consider in selecting which linker to use with
> the 64-bit port. The GNU 64-bit linker can only create dynamic binaries. The
> -static option causes linking with archive libraries but doesn't produce a
> truly static binary. Dynamic binaries still require final binding by the
> dynamic loader to resolve a set of dynamic-loader-defined symbols. The default
> behavior of the HP linker is the same as the GNU linker. However, it can
> generate true 64-bit static binaries using the +compat option. 
> 
> oddly changes:
> 
> The GNU 64-bit linker has some issues with shared library support and
> exceptions. As a result, we only support libgcc in archive format. For similar
> reasons, dwarf2 unwind and exception support are disabled. The GNU linker also
> has problems creating binaries with -static. It doesn't provide stubs for
> internal calls to global functions in shared libraries, so these calls can't be
> overloaded. 
> 
> I can see how people are confused by this. GNU ld appears to not really work
> with shared or static libs, from the docs. (But maybe just for 64 bit targets?)
> But experience says it works with static libs, but not shared libs. Something
> needs to be changed, and this section should be updated with the latest status
> and best practice (which appears to be GNU as, HPUX ld).  (FWIW, it looks like
> shared libgcc is being created on this target now with GNU ld or else this
> alone would turn off symbol versioning.) Some love here by people in the know
> would be helpful to all.

It's been awhile but I believe there never was an issue using archive
libraries.  There was a problem linking executables with -static that
I believe got fixed.

I agree this needs rewriting.  The problems with shared library support
are more important than the issues with -static.  However, some testing
is needed to determine the current state of GNU ld.

Dave

Created attachment 17164 [details]
Verbose output of static link step

As you can see for all libraries except libdld archives are used.

Created attachment 17165 [details]
chatr output for the resulting object

As you can see there is one dependency to libdl.1 what is ok AFAIK. There is no libdl archive.
In the segment index there are two unknown segments. That is with cvs binutils as of yesterday. But I think it's the same with binutils-2.16.1.

Subject: Re:  shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

> As you can see there is one dependency to libdl.1 what is ok AFAIK. There is no
> libdl archive.

Yes, there are a number of libraries that don't have archive versions.
I believe libdld needs the dynamic loader.  Another library is librt.
We try to handle this problem in the LIB_SPEC define.

> In the segment index there are two unknown segments. That is with cvs binutils
> as of yesterday. But I think it's the same with binutils-2.16.1.

Advise using recent version.  There are no recent fixes affecting
GNU ld on hpux, but there have been some assembler fixes.

I've seen the segment issue but don't have a fix.  There's something
going wrong in the core code.  I think this is the main issue with
shared libraries.

I tried a full native build last night with GNU ld.  It failed with
a broken f951 compiler.  The problem is pc-relative calls are broken
(no stub, or incorrect offset to stub) when the call distance exceeds
the maximum branch distance for the 22-bit pc-relative relocation.
This should be relatively straightforward to fix.

Dave

Subject: Bug 38384

Author: rwild
Date: Sat Dec  5 17:18:53 2009
New Revision: 155012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155012
Log:
Sync from git Libtool and regenerate.

/:
	PR target/38384
	PR bootstrap/40972
	* libtool.m4: Sync from git Libtool.
	* ltoptions.m4: Likewise.
	* ltversion.m4: Likewise.
	* lt~obsolete.m4: Likewise.
	* ltmain.sh: Likewise.

boehm-gc/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* include/Makefile.in: Regenerate.

fixincludes/:
	* configure: Regenerate.

gcc/:
	* configure: Regenerate.

libffi/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* include/Makefile.in: Regenerate.
	* man/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.

libgfortran/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.

libgomp/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* testsuite/Makefile.in: Regenerate.

libjava/classpath/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* doc/Makefile.in: Regenerate.
	* doc/api/Makefile.in: Regenerate.
	* examples/Makefile.in: Regenerate.
	* external/Makefile.in: Regenerate.
	* external/jsr166/Makefile.in: Regenerate.
	* external/relaxngDatatype/Makefile.in: Regenerate.
	* external/sax/Makefile.in: Regenerate.
	* external/w3c_dom/Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* lib/Makefile.in: Regenerate.
	* native/Makefile.in: Regenerate.
	* native/fdlibm/Makefile.in: Regenerate.
	* native/jawt/Makefile.in: Regenerate.
	* native/jni/Makefile.in: Regenerate.
	* native/jni/classpath/Makefile.in: Regenerate.
	* native/jni/gconf-peer/Makefile.in: Regenerate.
	* native/jni/gstreamer-peer/Makefile.in: Regenerate.
	* native/jni/gtk-peer/Makefile.in: Regenerate.
	* native/jni/java-io/Makefile.in: Regenerate.
	* native/jni/java-lang/Makefile.in: Regenerate.
	* native/jni/java-math/Makefile.in: Regenerate.
	* native/jni/java-net/Makefile.in: Regenerate.
	* native/jni/java-nio/Makefile.in: Regenerate.
	* native/jni/java-util/Makefile.in: Regenerate.
	* native/jni/midi-alsa/Makefile.in: Regenerate.
	* native/jni/midi-dssi/Makefile.in: Regenerate.
	* native/jni/native-lib/Makefile.in: Regenerate.
	* native/jni/qt-peer/Makefile.in: Regenerate.
	* native/jni/xmlj/Makefile.in: Regenerate.
	* native/plugin/Makefile.in: Regenerate.
	* resource/Makefile.in: Regenerate.
	* scripts/Makefile.in: Regenerate.
	* tools/Makefile.in: Regenerate.

libjava/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* gcj/Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.

libmudflap/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* testsuite/Makefile.in: Regenerate.

libobjc/:
	* configure: Regenerate.

libssp/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.

libstdc++-v3/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* doc/Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* libsupc++/Makefile.in: Regenerate.
	* po/Makefile.in: Regenerate.
	* python/Makefile.in: Regenerate.
	* src/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.

lto-plugin/:
	* configure: Regenerate.
	* Makefile.in: Regenerate.

zlib/:
	* Makefile.in: Regenerate.
	* configure: Regenerate.

Modified:
    trunk/ChangeLog
    trunk/boehm-gc/ChangeLog
    trunk/boehm-gc/Makefile.in
    trunk/boehm-gc/configure
    trunk/boehm-gc/include/Makefile.in
    trunk/fixincludes/ChangeLog
    trunk/fixincludes/configure
    trunk/gcc/ChangeLog
    trunk/gcc/configure
    trunk/libffi/ChangeLog
    trunk/libffi/Makefile.in
    trunk/libffi/configure
    trunk/libffi/include/Makefile.in
    trunk/libffi/man/Makefile.in
    trunk/libffi/testsuite/Makefile.in
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/Makefile.in
    trunk/libgfortran/configure
    trunk/libgomp/ChangeLog
    trunk/libgomp/Makefile.in
    trunk/libgomp/configure
    trunk/libgomp/testsuite/Makefile.in
    trunk/libjava/ChangeLog
    trunk/libjava/Makefile.in
    trunk/libjava/classpath/ChangeLog
    trunk/libjava/classpath/Makefile.in
    trunk/libjava/classpath/configure
    trunk/libjava/classpath/doc/Makefile.in
    trunk/libjava/classpath/doc/api/Makefile.in
    trunk/libjava/classpath/examples/Makefile.in
    trunk/libjava/classpath/external/Makefile.in
    trunk/libjava/classpath/external/jsr166/Makefile.in
    trunk/libjava/classpath/external/relaxngDatatype/Makefile.in
    trunk/libjava/classpath/external/sax/Makefile.in
    trunk/libjava/classpath/external/w3c_dom/Makefile.in
    trunk/libjava/classpath/include/Makefile.in
    trunk/libjava/classpath/lib/Makefile.in
    trunk/libjava/classpath/native/Makefile.in
    trunk/libjava/classpath/native/fdlibm/Makefile.in
    trunk/libjava/classpath/native/jawt/Makefile.in
    trunk/libjava/classpath/native/jni/Makefile.in
    trunk/libjava/classpath/native/jni/classpath/Makefile.in
    trunk/libjava/classpath/native/jni/gconf-peer/Makefile.in
    trunk/libjava/classpath/native/jni/gstreamer-peer/Makefile.in
    trunk/libjava/classpath/native/jni/gtk-peer/Makefile.in
    trunk/libjava/classpath/native/jni/java-io/Makefile.in
    trunk/libjava/classpath/native/jni/java-lang/Makefile.in
    trunk/libjava/classpath/native/jni/java-math/Makefile.in
    trunk/libjava/classpath/native/jni/java-net/Makefile.in
    trunk/libjava/classpath/native/jni/java-nio/Makefile.in
    trunk/libjava/classpath/native/jni/java-util/Makefile.in
    trunk/libjava/classpath/native/jni/midi-alsa/Makefile.in
    trunk/libjava/classpath/native/jni/midi-dssi/Makefile.in
    trunk/libjava/classpath/native/jni/native-lib/Makefile.in
    trunk/libjava/classpath/native/jni/qt-peer/Makefile.in
    trunk/libjava/classpath/native/jni/xmlj/Makefile.in
    trunk/libjava/classpath/native/plugin/Makefile.in
    trunk/libjava/classpath/resource/Makefile.in
    trunk/libjava/classpath/scripts/Makefile.in
    trunk/libjava/classpath/tools/Makefile.in
    trunk/libjava/configure
    trunk/libjava/gcj/Makefile.in
    trunk/libjava/include/Makefile.in
    trunk/libjava/testsuite/Makefile.in
    trunk/libmudflap/ChangeLog
    trunk/libmudflap/Makefile.in
    trunk/libmudflap/configure
    trunk/libmudflap/testsuite/Makefile.in
    trunk/libobjc/ChangeLog
    trunk/libobjc/configure
    trunk/libssp/ChangeLog
    trunk/libssp/Makefile.in
    trunk/libssp/configure
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/Makefile.in
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/doc/Makefile.in
    trunk/libstdc++-v3/include/Makefile.in
    trunk/libstdc++-v3/libsupc++/Makefile.in
    trunk/libstdc++-v3/po/Makefile.in
    trunk/libstdc++-v3/python/Makefile.in
    trunk/libstdc++-v3/src/Makefile.in
    trunk/libstdc++-v3/testsuite/Makefile.in
    trunk/libtool.m4
    trunk/ltmain.sh
    trunk/lto-plugin/ChangeLog
    trunk/ltoptions.m4
    trunk/ltversion.m4
    trunk/lt~obsolete.m4
    trunk/zlib/ChangeLog.gcj
    trunk/zlib/Makefile.in
    trunk/zlib/configure

There was a lot of patch activity for this PR. Is it fixed?

(In reply to Steven Bosscher from comment #50)
> There was a lot of patch activity for this PR. Is it fixed?

I guess so