[Bug bootstrap/19461] New: hidden __eprintf referenced by DSO, gas+gld

[Bug bootstrap/19461] New: hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

Bootstrapping in a unified tree, LAST_UPDATED "Fri Jan 14 01:28:39 UTC 2005"
(together with gas and ld) with srcdir/configure --disable-nls
(because without that, I get missing NLS-related symbols, but that's another
story), from a gcc-2.95.2 installation and using GNU make, I get this error
(cut-n-pasted):

...
mkdir .libs
/tmp/hptmp/obj/gcc/g++ -shared-libgcc -B/tmp/hptmp/obj/gcc/ -nostdinc++
-B/usr/local/sparc-sun-solaris2.8/bin/ -B/usr/local/sparc\
-sun-solaris2.8/lib/ -isystem /usr/local/sparc-sun-solaris2.8/include -isystem
/usr/local/sparc-sun-solaris2.8/sys-include -g -O2\
 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0
-DLOCALEDIR=/tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc\
++-v3/po/share/locale -g -O2 -o abi_check abi_check.o 
-L/tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc++-v3/src -L/tmp/hptmp/obj/sp\
arc-sun-solaris2.8/libstdc++-v3/src/.libs -L/tmp/hptmp/obj/ld -lv3test
-L/tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc++-v3/testsui\
te -lm -Wl,--rpath -Wl,/tmp/hptmp/obj/gcc -Wl,--rpath
-Wl,/tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc++-v3/src/.libs
/tmp/hptmp/obj/gcc/collect-ld: abi_check: hidden symbol `__eprintf' in
/tmp/hptmp/obj/gcc/libgcc.a(_eprintf.o) is referenced by D\
SO
/tmp/hptmp/obj/gcc/collect-ld: final link failed: Nonrepresentable section on
output
collect2: ld returned 1 exit status
make[4]: *** [abi_check] Error 1
make[4]: Leaving directory
`/tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc++-v3/testsuite'

This might very well be a binutils bug, but better start at the top.
I need a bug-report I can point to, that explains why I test a patch
for *another* bug without c++/libstdc++.

-- 
           Summary: hidden __eprintf referenced by DSO, gas+gld
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-15 19:08 -------
http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00409.html
hmm, I don't know if that was with the native tools or not.



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
            Version|unknown                     |4.0.0


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-15 19:14 -------
Which binutils version?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |WAITING


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-15 19:20 -------
> http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00409.html
> hmm, I don't know if that was with the native tools or not.

Native, as neither --with-gnu-as not --with-gnu-ld is specified.

But I successfully bootstrapped with Binutils 2.15.94 CVS on 01/09 and with
Binutils 2.15 CVS on 01/01.


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-15 20:17 -------
No, this is with gas and GNU ld, as I said:

Using `/tmp/hptmp/combined/gcc/config/sparc/sparc.c' for machine-specific logic.
Using `/tmp/hptmp/combined/gcc/config/sparc/sparc.md' as machine description
file.
Using the following target machine macro files:
        /tmp/hptmp/combined/gcc/config/sparc/biarch64.h
        /tmp/hptmp/combined/gcc/config/sparc/sparc.h
        /tmp/hptmp/combined/gcc/config/dbxelf.h
        /tmp/hptmp/combined/gcc/config/elfos.h
        /tmp/hptmp/combined/gcc/config/svr4.h
        /tmp/hptmp/combined/gcc/config/sparc/sysv4.h
        /tmp/hptmp/combined/gcc/config/sol2.h
        /tmp/hptmp/combined/gcc/config/sparc/sol2.h
        /tmp/hptmp/combined/gcc/config/sparc/sol2-gld.h
        /tmp/hptmp/combined/gcc/config/sparc/sol2-gas.h
        /tmp/hptmp/combined/gcc/config/sparc/sol2-bi.h
        /tmp/hptmp/combined/gcc/config/tm-dwarf2.h
        /tmp/hptmp/combined/gcc/config/sparc/sol2-gld-bi.h
        /tmp/hptmp/combined/gcc/config/sparc/sol2-gas-bi.h
Using host-solaris.o for host machine hooks.
checking whether NLS is requested... no
checking what assembler to use... "newly built gas"
checking what linker to use... "newly built ld"
checking what nm to use... "newly built nm"
checking what objdump to use... "newly built objdump"
checking assembler for .balign and .p2align... yes
checking assembler for .p2align with maximum skip... yes
checking assembler for working .subsection -1... yes
checking assembler for .weak... yes
checking assembler for .nsubspa comdat... yes
checking assembler for .hidden... yes
checking linker for .hidden support... yes
checking assembler for .sleb128 and .uleb128... yes
checking assembler for eh_frame optimization... yes
checking assembler for section merging support... yes
checking assembler for COMDAT group support... yes
checking assembler for thread-local storage support... yes
checking linker -Bstatic/-Bdynamic option... yes
checking assembler for .register... yes
checking assembler for -relax option... no
checking assembler for unaligned pcrel relocs... no
checking assembler for offsetable %lo()... no
checking assembler for dwarf2 debug_line support... yes
checking assembler for buggy dwarf2 .file directive... no
checking assembler for --gdwarf2 option... yes
checking assembler for --gstabs option... yes
checking linker read-only and read-write section mixing... read-write
checking linker PT_GNU_EH_FRAME support... yes
checking linker position independent executable support... yes
checking linker --as-needed support... no
Using ggc-page for garbage collection.
checking whether to enable maintainer-specific portions of Makefiles... no
Links are now set up to build a native compiler for sparc-sun-solaris2.8.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-01-15 20:17:49
               date|                            |


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-15 20:19 -------
Oh, you meant what binutils was used at the testresults URL!

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-15 20:22 -------
Still since Eric could bootstrap with the GNU binutils, this almost has to be a binutils bug. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-15 22:06 -------
I just bootstrapped C,C++ mainline against Binutils 2.15 CVS without a hitch:

_eprintf.o:     file format elf32-sparc

SYMBOL TABLE:
00000000 l    df *ABS*  00000000 libgcc2.c
00000000 l    d  .text  00000000
00000000 l    d  .data  00000000
00000000 l    d  .bss   00000000
00000000 l    d  .debug_abbrev  00000000
00000000 l    d  .debug_info    00000000
00000000 l    d  .debug_line    00000000
00000000 l    d  .debug_frame   00000000
00000000 l    d  .debug_pubnames        00000000
00000000 l    d  .debug_aranges 00000000
00000000 l    d  .debug_str     00000000
00000000 l    d  .comment       00000000
00000008 g     F .text  00000048 .hidden __eprintf
00000000         *UND*  00000000 __iob
00000000         *UND*  00000000 _GLOBAL_OFFSET_TABLE_
00000000         *UND*  00000000 fprintf
00000000         *UND*  00000000 fflush
00000000         *UND*  00000000 abort

I'd suggest to try with at least Binutils 2.14 (2.15 Release is broken).


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-15 22:31 -------
Will cvs up binutils and retry.
(Oh my.  It might actually be that the checkout
is from before your recent .hidden/_GOT_-whatever
bfd fix!)

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-19 07:27 -------
Closing as you reported a successful C,C++,Obj-C,Java bootstrap.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-19 09:34 -------
Reopening PR, as the report supposedly referred to in comment #9
was with native tools (/usr/ccs/bin something).
I hope to close this PR in a day or two pending a bootstrap with gas+ld.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-20 16:37 -------
With binutils bfd/version.h:
#define BFD_VERSION_DATE 20050115
and everything else as in original
description, I still get the same error.
(Needed to rm -rf gprof to get past
a binutils-specific error.)
Will now try today's binutils CVS.

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 17:01 -------
> With binutils bfd/version.h:
> #define BFD_VERSION_DATE 20050115
> and everything else as in original
> description, I still get the same error.

Ouch!  Daniel Jacobowitz once said this error can originate in an old assert.h
lying around somewhere.

I can tell you that I can bootstrap current GCC mainline with all languages
enabled and Binutils 2.15 CVS or 2.15.94 CVS on the 5 SPARC/Solaris machines I
have access to (Solaris 2.5.1, 2.6, 7, 8 and 9).


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-21 02:07 -------
(Please be more specific than e.g. "current GCC mainline".)
With binutils of "2005-01-20 15:37:12 UTC"
and GCC of "Fri Jan 14 01:28:39 UTC 2005"
I still get the same error.
Now updating gcc.

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-21 05:19 -------
> (Please be more specific than e.g. "current GCC mainline".)

Well, I bootstrapped the day you opened the PR... And no, it wasn't an accident,
I haven't got any problem boostrapping with Binutils since at least 01/01.


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-21 16:49 -------
A build with GCC CVS LAST_UPDATED "Fri Jan 21 03:20:28 UTC 2005"
also fails in the same way.  I don't have a pressing need to get
this fixed, as my bootstrap-test needs are covered by native
tools, but if wanted, I can dig up details, for example a tarball
with the failing objects.

Anyway, I did some digging myself.  Apparently the failing link
calls /usr/ccs/bin/ld, despite gcc otherwise using the newly built
ld!  Could it be that --with-gnu-as --with-gnu-ld is actually
required also in a combined tree? (If so, there's a consistency bug.
If not, it's a collect2 bug.) But maybe this is a red herring.

To repeat the problem, I think a machine with no GNU tools installed
is required, and maybe also required to start the build with gcc-2.95.2.


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-21 17:09 -------
Following up on comment #18, no GNU ld *is* used, it's just that
adding -print-prog-name=ld to the failing link says "/usr/ccs/bin/ld".
An otherwise harmless bug, likely a WONTFIX. :-)  But that's another bug.
(There is no other ld in the newly build search path; what's used is
the link collect-ld, which points to ../ld/ld-new.)

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-21 17:11 -------
(Oops, I meant comment #15 in comment #16.
It's my "bug list" that's 18. :-)

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-21 17:27 -------
> A build with GCC CVS LAST_UPDATED "Fri Jan 21 03:20:28 UTC 2005"
> also fails in the same way.  I don't have a pressing need to get
> this fixed, as my bootstrap-test needs are covered by native
> tools, but if wanted, I can dig up details, for example a tarball
> with the failing objects.

I agree, this is not really urgent.  Very few people do combined builds on
SPARC/Solaris.  I personally always specify both --with-as and --with-gnu-as
when I use the GNU tools because I've had my share of problems too (although
never this one, IIRC the build aborts earlier).

> Anyway, I did some digging myself.  Apparently the failing link
> calls /usr/ccs/bin/ld, despite gcc otherwise using the newly built
> ld!  Could it be that --with-gnu-as --with-gnu-ld is actually
> required also in a combined tree? (If so, there's a consistency bug.
> If not, it's a collect2 bug.) But maybe this is a red herring.

OK, I've already run into something like that: although you specify both
--with-gnu-as and --with-gnu-ld and GNU as and ld are first in the PATH, the Sun
tools are nevertheless used at some point.


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-21 17:38 -------
Digging further, there *is* a __eprintf reference in
/tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc++-v3/src/.libs/libstdc++.so,
the one supposedly complained about when building the test-application.
Now, how did it get there?
Ah, it's in debug.o, from libstdc++-v3/src/debug.cc.
Apparently from the asserts there, likely from the gcc-2.95.2
installation? Perhaps we need to fixinclude away all __eprintf usage?
Strange that libstdc++.so could be created but not used (linked to).
Supposedly because there's another, non-hidden __eprintf somewhere?

I seem to recall a related problem discussed some time the last few
months.  I don't remember the resolution.  Maybe it was seen on darwin?


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-21 17:41 -------
To clarify, comment #16 should read "No: GNU ld is actually used":
that is, an affirmation that GNU ld is used, contrary to comment #15.
(It could be read as the negation, and we have enough confusion.
I'm not sure I helped now. :-)

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-05-18 21:03 -------
Habitual reconfirm.

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-15 21:53 -------
Does this work now?

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-07-15 22:11 -------
> Does this work now?

Nothing has really changed, the problem very likely comes from the bootstrap
compiler.  Nobody will fix this so I think the PR should be closed as WONTFIX.

-- 


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