[Bug libstdc++/38384] New: fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[Bug libstdc++/38384] New: fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3303 bytes --]

fails with:
gmake[4]: Entering directory
`/home/SCRATCH/tmp.eoeYZr5823/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/libmath'
/bin/sh ../libtool --tag CC --tag=CC --mode=compile
/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc
-B/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/
-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
-DHAVE_CONFIG_H -I. -I/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath -I..
    -g -O2   -c -o stubs.lo
/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c
libtool: compile: 
/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc
-B/SCRATCH/tmp.eoeYZr5823/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/
-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
-DHAVE_CONFIG_H -I. -I/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath -I..
-g -O2 -c /opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c  -DPIC
-o .libs/stubs.o
/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c:39: error:
expected identifier or ‘(’ before ‘float’
/opt/gnu/src/gcc/gcc-4.4.0-test/libstdc++-v3/libmath/stubs.c:39: error:
expected ‘)’ before ‘fabs’
gmake[4]: *** [stubs.lo] Error 1
gmake[4]: Leaving directory
`/home/SCRATCH/tmp.eoeYZr5823/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/libmath'
gmake[3]: *** [all-recursive] Error 1


-- 
           Summary: fails to build cross gcc for target hppa64-hp-hpux11.00
                    in libstdc++/libmath
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: r dot emrich at de dot tecosim dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: hppa64-hp-hpux11.00


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #1 from r dot emrich at de dot tecosim dot com  2008-12-03 16:30 -------
Created an attachment (id=16815)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16815&action=view)
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);
}



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #2 from r dot emrich at de dot tecosim dot com  2008-12-08 17:08 -------
(In reply to comment #1)
> Created an attachment (id=16815)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16815&action=view) [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__ */  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[danglin at gcc dot gnu dot org]

------- Comment #3 from danglin at gcc dot gnu dot org  2008-12-13 00:37 -------
This doesn't occur in native builds because:

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


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #4 from r dot emrich at de dot tecosim dot com  2008-12-29 12:14 -------
Created an attachment (id=16999)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16999&action=view)
libstdc++/config.log

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2008-12-29 16:34 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #6 from r dot emrich at de dot tecosim dot com  2008-12-29 17:11 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[bkoz at gcc dot gnu dot org]

------- Comment #7 from bkoz at gcc dot gnu dot org  2009-01-05 20:38 -------
Created an attachment (id=17035)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17035&action=view)
add fabsf for hpux10/11


Try this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[bkoz at gcc dot gnu dot org]

------- Comment #8 from bkoz at gcc dot gnu dot org  2009-01-05 20:48 -------

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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[bkoz at gcc dot gnu dot org]

------- Comment #9 from bkoz at gcc dot gnu dot org  2009-01-05 20:50 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #10 from r dot emrich at de dot tecosim dot com  2009-01-06 10:20 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-06 14:49 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-07 00:10 -------
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


------- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-07 00:10 -------
Created an attachment (id=17040)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17040&action=view)


------- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-07 00:10 -------
Created an attachment (id=17041)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17041&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[bkoz at gcc dot gnu dot org]

------- Comment #15 from bkoz at gcc dot gnu dot org  2009-01-09 19:40 -------

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


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-09 19:40:56
               date|                            |
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-10 16:35 -------
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


------- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-10 16:35 -------
Created an attachment (id=17071)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17071&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[bkoz at gcc dot gnu dot org]

------- Comment #18 from bkoz at gcc dot gnu dot org  2009-01-12 23:59 -------

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? 


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[bkoz at gcc dot gnu dot org]

------- Comment #19 from bkoz at gcc dot gnu dot org  2009-01-13 01:49 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #20 from r dot emrich at de dot tecosim dot com  2009-01-14 13:58 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #21 from r dot emrich at de dot tecosim dot com  2009-01-14 18:47 -------
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. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #22 from r dot emrich at de dot tecosim dot com  2009-01-15 13:07 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #23 from r dot emrich at de dot tecosim dot com  2009-01-16 15:01 -------
Created an attachment (id=17118)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17118&action=view)
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[rwild at gcc dot gnu dot org]

------- Comment #24 from rwild at gcc dot gnu dot org  2009-01-16 15:13 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-16 15:14 -------
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)
>  --> (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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #26 from r dot emrich at de dot tecosim dot com  2009-01-16 16:07 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-16 16:15 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #28 from r dot emrich at de dot tecosim dot com  2009-01-16 16:17 -------
Created an attachment (id=17119)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17119&action=view)
fix file magic regex for hppa*64*

updated patch


-- 

r dot emrich at de dot tecosim dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17118|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #29 from r dot emrich at de dot tecosim dot com  2009-01-16 16:45 -------
Created an attachment (id=17120)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17120&action=view)
fix file magic regex for HP-UX hosts

updated patch for all HP-UX hosts.


-- 

r dot emrich at de dot tecosim dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17119|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #30 from r dot emrich at de dot tecosim dot com  2009-01-16 16:51 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-16 17:21 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #32 from r dot emrich at de dot tecosim dot com  2009-01-16 18:33 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #33 from r dot emrich at de dot tecosim dot com  2009-01-19 10:51 -------
(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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #34 from r dot emrich at de dot tecosim dot com  2009-01-19 10:52 -------
Created an attachment (id=17140)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17140&action=view)
C compile log


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #35 from r dot emrich at de dot tecosim dot com  2009-01-19 10:53 -------
Created an attachment (id=17141)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17141&action=view)
C compile static log


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #36 from r dot emrich at de dot tecosim dot com  2009-01-19 10:53 -------
Created an attachment (id=17142)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17142&action=view)
C++ compile log


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

------- Comment #37 from r dot emrich at de dot tecosim dot com  2009-01-19 10:54 -------
Created an attachment (id=17143)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17143&action=view)
C++ compile static log


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-19 13:38 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[bkoz at gcc dot gnu dot org]

------- Comment #39 from bkoz at gcc dot gnu dot org  2009-01-20 20:02 -------

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


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|bkoz at gcc dot gnu dot org |unassigned at gcc dot gnu
                   |                            |dot org
             Status|WAITING                     |NEW
          Component|libstdc++                   |target
            Summary|fails to build cross gcc for|link/execute fails for cross
                   |target hppa64-hp-hpux11.00  |gcc from linux to target
                   |in libstdc++/libmath        |hppa64-hp-hpux11.00


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #40 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-20 20:23 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[r dot emrich at de dot tecosim dot com]

------- Comment #41 from r dot emrich at de dot tecosim dot com  2009-01-22 18:15 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #42 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-22 18:42 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[bkoz at gcc dot gnu dot org]

------- Comment #43 from bkoz at gcc dot gnu dot org  2009-01-22 21:40 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[bkoz at gcc dot gnu dot org]

------- Comment #44 from bkoz at gcc dot gnu dot org  2009-01-22 22:01 -------

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.


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation
            Summary|link/execute fails for cross|shared link/execute fails
                   |gcc from linux to target    |for cross gcc from linux to
                   |hppa64-hp-hpux11.00         |target hppa64-hp-hpux11.00


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #45 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-22 22:36 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[r dot emrich at de dot tecosim dot com]

------- Comment #46 from r dot emrich at de dot tecosim dot com  2009-01-23 10:45 -------
Created an attachment (id=17164)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17164&action=view)
Verbose output of static link step

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[r dot emrich at de dot tecosim dot com]

------- Comment #47 from r dot emrich at de dot tecosim dot com  2009-01-23 10:50 -------
Created an attachment (id=17165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17165&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #48 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-23 17:41 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |4.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.1                       |4.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.2                       |4.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[rwild at gcc dot gnu dot org]

------- Comment #49 from rwild at gcc dot gnu dot org  2009-12-05 17:19 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.3                       |4.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.4                       |4.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384