Bug #31268 Build failure on host 'sol10-amd64-a', build does not find 64bit libstdc++

Description:
Lots of link error messages such as:

ld: fatal: file /usr/local/bin/../lib/gcc/i386-pc-solaris2.10.1/3.4.3/../../..//libstdc++.so: wrong ELF class: ELFCLASS32

This only occurs if Falcon is configured to be built since Falcon requires libstdc++. The build appears to be finding a 32bit library and not the 64bit library.

How to repeat:
Build on host 'sol10-amd64-a' and ensure that Falcon is to be compiled.

Suggested fix:
Make sure that 64bit libraries are installed properly and paths are correct.

Thank you for a problem report. Please, send the result of:

echo $LD_LIBRARY_PATH

Do you have 64-bit version at all on that system?

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/36422

ChangeSet@1.2648, 2007-10-26 02:52:17-07:00, antony@pcg5ppc.xiphis.org +1 -0
  Bug#31268
    "Build failure on host sol10-amd64-a
    Add test to check if libstdc++ really works

Nailing this down was really interesting, there are actually
three problems :-)

The first one is that only adding "-m64" is not enough to inform
the build that this is a 64 bit build. It just happen to work in
most cases (config.guess will claim it is i386). The solution is
to configure with the option

  --build=x86_64-pc-solaris2.10

The second problem is that the configure script will dig out
what "GCC system library paths" to use with something like

  if $GCC; $CC -print-search-dirs | ....

and $CC contains no information about if a 32 or 64 bit
build, i.e. $CFLAGS was left out where the "-m64" is.

The third problem is that this version of gcc with the 
"-print-search-dirs" flag output the 32 bit paths even if
"-m64" is given.

The work around is to give the flag above, and set in the
environment when configuring

  LIBRARY_PATH="/usr/local/lib/amd64"

Another solution would of course be to try upgrade to
tools that has these problems corrected :-)

Current tools used are

  gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
  automake (GNU automake) 1.9.6
  autoconf (GNU Autoconf) 2.59
  libtoolize (GNU libtool) 1.5.22

The "-lstdc++" comes from the added configure options part
of the Falcon plugin/engine. If we really want one engine
to force us to add exceptions and stdc++ dependency is
another question outside the scope of this bug report.

The problem with "-m64" not passed to "gcc -print-search-paths"
seem to be fixed in libtool 1.5.24, at least the code doing
this check now handles "multilibs".

I think no documentation change is needed for this, unless
some hints should be added to the Solaris specific page.
The hint would be something like

  Building a 64-bit binary on Solaris AMD64 with gcc might fail.
  Not going into why (see bug#31268), you can work around this by
  forcing the build to be 64-bit

  o Give "--build=x86_64-pc-solaris2.10" as a configure argument

  o Give "-m64" part of CFLAGS, CXXFLAGS and LDFLAGS

  o Configure and run make like

    % LIBRARY_PATH=/usr/local/lib/amd64 ./configure .....
    % LIBRARY_PATH=/usr/local/lib/amd64 gmake

Noted bugfix in 6.0.4 changelog.

Updated source installation instructions per comments from Kent and IRC discussion with Danny and Joerg.