[Bug c++/14869] New: count of external relocation entries does not match

[Bug c++/14869] New: count of external relocation entries does not match

[rwgk at yahoo dot com]

Under Mac OS 10.3.2 linking some Boost.Python extensions fails.

g++ (GCC) 3.5.0 20040406 (experimental)

Configured with: /net/worm/scratch1/rwgk/gcc_cvs_head/configure --
prefix=/usr/local_cci/gcc_cvs_head_20040406 --enable-languages=c,c++

Apple G5 under OS 10.3.2:
Darwin coral.lbl.gov 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55
PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC  Power Macintosh powerpc

Example error message:

g++ -w -bundle -framework Python -o libtbx/cctbx_crystal_ext.so 
cctbx/crystal/boost_python/crystal_ext.os 
cctbx/crystal/boost_python/direct_space_asu.os 
cctbx/crystal/boost_python/neighbors.os -Llibtbx -
L/net/worm/scratch1/rwgk/hot/libtbx -lcctbx -lscitbx_boost_python -
lboost_python -lm
/usr/bin/ld: internal error: output_section() count of external relocation 
entries does not match

collect2: ld returned 1 exit status


Most of our extension modules link just fine with the same switches and 
libraries. All Boost.Python regression tests link fine as well.

If this is not a known problem I will create a self-contained package that you 
can use to reproduce the error. (It will be large because I will have to 
include the complete Boost tree.)

-- 
           Summary: count of external relocation entries does not match
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rwgk at yahoo dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.2.0
  GCC host triplet: powerpc-apple-darwin7.2.0
GCC target triplet: powerpc-apple-darwin7.2.0


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

[Bug c++/14869] count of external relocation entries does not match

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-06 22:07 -------
This is not a known bug at least have not seen it before, please add a self contained example.  But then 
again this could be a ld bug in that case it needs to be filed with Apple.

-- 


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

[Bug c++/14869] count of external relocation entries does not match

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-07 03:41 -------
Also note bundles cannot link with any libraries, I am wondering how this worked at all.

-- 


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

[Bug c++/14869] count of external relocation entries does not match

[rwgk at yahoo dot com]

------- Additional Comments From rwgk at yahoo dot com  2004-04-08 17:36 -------
A large (11MB) but self-contained reproducer is available at this location:

http://cci.lbl.gov/~rwgk/bugs/gcc350/dbg_gcc350_20040406.tar.gz

Requirements:
  Mac OS 10.3 (we are using 10.3.2)
  Xcode Tools (we are using v1.1)

Xcode Tools is required because this installs the Python include files.

I've spent some time narrowing down the issue a little bit. The problem appears 
to be related to the number of recursive uses of chaining. E.g. a simplified 
version of typical Boost.Python bindings:

  class_<some_type>("some_type")
    .def("member_function_1", &some_type::member_function_1)
    .def("member_function_2", &some_type::member_function_2)
    //...
    .def("member_function_n", &some_type::member_function_n)
  ;

The link error occurs only if there are too many .def()'s.

I've set up two demos, demo_ok.csh and demo_fail.csh:

gunzip -c dbg_gcc350_20040406.tar.gz | tar xf -
cd dbg_gcc350_20040406
./demo_ok.csh # this will take a few minutes and there should be no errors
./demo_fail.csh # this should take less than a minute and end with an error

The outputs that I got here are in log_ok and log_fail in the tar file.

The only difference between the two demos is a define at the top of the file:

cctbx/crystal/boost_python/direct_space_asu.cpp

(Depending on the demo script used, the file is a copy of 
direct_space_asu_ok.cpp or direct_space_asu_fail.cpp in the same directory).

The define leads to one additional .def() being compiled via demo_fail.csh. 
I've done simple replacement experiments indicating that it doesn't matter 
which of the disabled .def()'s is added. I guess any additional .def() leads to 
the link error.

The exact same source code compiles and links fine with Apple's compiler (gcc 
version 3.3 20030304 (Apple Computer, Inc. build 1495)).


-- 


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

[Bug c++/14869] count of external relocation entries does not match

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-08 18:44 -------
I can confirm this, I will look into the asm to see if this is really a GCC bug, I almost spect this is an as 
or a ld bug, in which case you should report this to Apple.

-- 


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

[Bug c++/14869] count of external relocation entries does not match

[rwgk at yahoo dot com]

------- Additional Comments From rwgk at yahoo dot com  2004-04-24 05:50 -------
I've upgraded the OS from 10.3.2 to 10.3.3. In doing so the time stamp 
on /usr/bin/ld changed (Apr 15).

I've upgraded the Xcode tools from v1.1 to v1.2.

I've checked out the latest gcc CVS head (g++ (GCC) 3.5.0 20040424 
(experimental)) to make bootstrap; make; make install using the new Xcode tools 
v1.2.

Unfortunately the "count of external relocation entries does not match" message 
persists.

The good news is that all of the Boost.Python tests compile, link and execute 
without a problem using Apple's latest compiler (gcc version 3.3 20030304 
(Apple Computer, Inc. build 1640)); the first time ever, to my knowledge.


-- 


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

[Bug c++/14869] count of external relocation entries does not match

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-25 06:32 -------
Fixed on the mainline, maybe because the requirement for cc-tools-528 but it could also because it 
was fixed in the compiler but I doubt that.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.5.0


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