Re: 64-bit configure hell

Re: 64-bit configure hell

[Benjamin Kosnik]

I think if you search through libstdc++ bugzilla you will find reports
of oddness with x86_64 systems and the 64 bit multilib. To me, if you
have to disable multilibs on 32/64 bit systems to get a working
toolchain, something is wrong.

I haven't paid much attention to these bug reports. Some people have
problems (HJ) and others do not (Jakub, Paolo, others). 

If you can provide a real problem description, and examples of the
libstdc++ build/configure hacks you use to work around it, it would be
helpful.

-benjamin

Re: 64-bit configure hell

[Stan Shebs]

Benjamin Kosnik wrote:

>I think if you search through libstdc++ bugzilla you will find reports
>of oddness with x86_64 systems and the 64 bit multilib. To me, if you
>have to disable multilibs on 32/64 bit systems to get a working
>toolchain, something is wrong.
>
>
Exactly.

>I haven't paid much attention to these bug reports. Some people have
>problems (HJ) and others do not (Jakub, Paolo, others). 
>
>If you can provide a real problem description, and examples of the
>libstdc++ build/configure hacks you use to work around it, it would be
>helpful.
>
It's hard for anybody outside Apple to reproduce on Darwin right now,
because you need an up-to-the-minute Tiger with all the trimmings,
but you could kludge up a similar situation by taking a standard x86
Linux config and defining a multilib with a -m codegen option that
produces code that can't possibly run on the CPU you're using to
build things. The tools are fine with building shlibs and even
executables for that -m option, but you can't run any of it until
you've moved to the right kind of CPU. (You might have to add code
to the little conftest programs to guarantee the exectime failure,
depending on the -m option you use.)

The crux of the problem seems to be _AC_COMPILER_EXEEXT_WORKS in
autoconf's lang.m4, which looks like it fishes for a usable file
extension by trying to run programs with various names.

Stan

Re: 64-bit configure hell

[Peter O'Gorman]

Stan Shebs wrote:

> The crux of the problem seems to be _AC_COMPILER_EXEEXT_WORKS in
> autoconf's lang.m4, which looks like it fishes for a usable file
> extension by trying to run programs with various names.

Isn't this what AC_NO_EXECUTABLES (also in lang.m4) is for?

from cvs autoconf's lang.m4:
# AC_NO_EXECUTABLES
# -----------------
# FIXME: The GCC team has specific needs which the current Autoconf
# framework cannot solve elegantly.  This macro implements a dirty
# hack until Autoconf is able to provide the services its users
# need.
#
# Several of the support libraries that are often built with GCC can't
# assume the tool-chain is already capable of linking a program: the
# compiler often expects to be able to link with some of such
# libraries.
#
# In several of these libraries, workarounds have been introduced to
# avoid the AC_PROG_CC_WORKS test, that would just abort their
# configuration.  The introduction of AC_EXEEXT, enabled either by
# libtool or by CVS autoconf, have just made matters worse.
#
# Unlike an earlier version of this macro, using AC_NO_EXECUTABLES does
# not disable link tests at autoconf time, but at configure time.
# This allows AC_NO_EXECUTABLES to be invoked conditionally.
AC_DEFUN_ONCE([AC_NO_EXECUTABLES],
[m4_divert_push([KILL])
m4_divert_text([DEFAULTS], [ac_no_link=no])

AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])
AC_BEFORE([$0], [AC_LINK_IFELSE])

m4_define([_AC_COMPILER_EXEEXT],
[AC_LANG_CONFTEST([AC_LANG_PROGRAM()])
if AC_TRY_EVAL(ac_link); then
   ac_no_link=no
   ]m4_defn([_AC_COMPILER_EXEEXT])[
else
   ac_no_link=yes
   # Setting cross_compile will disable run tests; it will
   # also disable AC_CHECK_FILE but that's generally
   # correct if we can't link.
   cross_compiling=yes
   EXEEXT=
   _AC_COMPILER_EXEEXT_CROSS
fi
])

m4_define([AC_LINK_IFELSE],
[if test x$ac_no_link = xyes; then
   AC_MSG_ERROR([Link tests are not allowed after AC@&t@_NO_EXECUTABLES.])
fi
]m4_defn([AC_LINK_IFELSE]))

m4_divert_pop()dnl
])# AC_NO_EXECUTABLES

Peter
-- 
Peter O'Gorman - http://www.pogma.com

Re: 64-bit configure hell

[Peter O'Gorman]

Peter O'Gorman wrote:
> Stan Shebs wrote:
> 
>> The crux of the problem seems to be _AC_COMPILER_EXEEXT_WORKS in
>> autoconf's lang.m4, which looks like it fishes for a usable file
>> extension by trying to run programs with various names.
> 
> 
> Isn't this what AC_NO_EXECUTABLES (also in lang.m4) is for?

Love replying to my own messages, makes me feel stupid to have sent the 
first one :/

config/no-executables.m4 defines GCC_NO_EXECUTABLES which is the same macro, 
  and is used in libstdc++'s configure.ac. It should probably be used 
unconditionally.

Peter

Re: 64-bit configure hell

[Bill Northcott]

> From: Stan Shebs <shebs@apple.com>
> It's hard for anybody outside Apple to reproduce on Darwin right now,
> because you need an up-to-the-minute Tiger with all the trimmings,
> but you could kludge up a similar situation by taking a standard x86
> Linux config and defining a multilib with a -m codegen option that
> produces code that can't possibly run on the CPU you're using to
> build things. The tools are fine with building shlibs and even
> executables for that -m option, but you can't run any of it until
> you've moved to the right kind of CPU. (You might have to add code
> to the little conftest programs to guarantee the exectime failure,
> depending on the -m option you use.)
>
I ran into this a couple of days back.  I pulled tag apple-gcc-4020 off 
the cvs and built it.

Because I wanted fortran, libffi and libobjc-gnu I futzed about with 
the build_gcc script that sets the options on the build.  Unwittingly, 
I changed a version number in the script and it tried to build a 64bit 
libgcc with -m64 option.  It fell over at the first hurdle because I 
did not have the ppc64 headers, which I presume are unavailable outside 
Apple.

I will post the good news in a separate message.

Bill Northcott

Re: 64-bit configure hell

[Mike Stump]

On Thursday, November 25, 2004, at 10:18  PM, Bill Northcott wrote:
> Unwittingly, I changed a version number in the script and it tried to 
> build a 64bit libgcc with -m64 option.

It is supposed to sense the 32-bit only-ness of your system, and avoid 
the 64 bit stuff. :-(  Oh well.

Be sure to rebuild clean...  It should wind up using the darwin7 
triplet as I recall, and that should avoid most of the 64-bit stuff.

Re: 64-bit configure hell

[Ulrich Weigand]

Benjamin Kosnik wrote:

>I think if you search through libstdc++ bugzilla you will find reports
>of oddness with x86_64 systems and the 64 bit multilib. To me, if you
>have to disable multilibs on 32/64 bit systems to get a working
>toolchain, something is wrong.

In my experience, the main problem is that in order to build 32-bit
libraries you need 32-bit development libraries (libc.a, crt*.o)
installed on the system, and many distributions don't install
those by default.  (Or vice versa on systems that use a mostly-32-bit
userland.)

I guess one way to fix this problem would be to only build those
multilibs where the required system dependencies are in fact installed;
this could be verified by attempting to build a 'hello world' using
the multilib flags.  If this already fails, there's no point in
attempting to build the library.

Something like that is actually attempted in config-ml.in, at least
for some platforms.  However this doesn't work, as those checks are
not applied for libgcc (and thus we fail already there).  I think I
pointed this out already some time in the past, and was told that
this is difficult to fix with the current make process ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: 64-bit configure hell

[Rainer Orth]

Ulrich Weigand <Ulrich.Weigand@de.ibm.com> writes:

> I guess one way to fix this problem would be to only build those
> multilibs where the required system dependencies are in fact installed;
> this could be verified by attempting to build a 'hello world' using
> the multilib flags.  If this already fails, there's no point in
> attempting to build the library.
> 
> Something like that is actually attempted in config-ml.in, at least
> for some platforms.  However this doesn't work, as those checks are
> not applied for libgcc (and thus we fail already there).  I think I
> pointed this out already some time in the past, and was told that
> this is difficult to fix with the current make process ...

Indeed: libgcc would have to be moved to the toplevel, since you need the
stage 1 compiler to perform this test.  The bootstrap compiler may not be
gcc (so require multilib flags different from gcc's) or not be
multilib-aware.

	Rainer

64-bit configure hell

[Stan Shebs]

I have a messy configure problem with 64-bit Darwin, and would
like to get some ideas about how to solve. The situation is that
Darwin 8.x aka Tiger is capable of running 64-bit-address-space
programs on G5s, and to support that in GCC I've set up a multilib
for the -m64 option that enables it. This all works on G5 Tiger
now, at least on prime-number days of the month when the moon is
full :-) , and I hope to check in the last bits soon.

The problem is that Tiger also runs on G4s, which are not capable
of running 64-bit programs - all the machinery is there to build
complete and correct binaries, the kernel just refuses to execute
them. This causes problems for some configure scripts, in particular
those in libstdc++ and libobjc, which want to be able to run
executables. It's not entirely clear to me why that's important,
since the libraries already build and run perfectly fine for
cross-compilers.

Although it would be good for sales to require that people
building GCC on Darwin upgrade to G5s :-) that's kind of
unfriendly, while producing different results from configure
and make depending on one's CPU is also just asking for
trouble. What other options do I have?

Stan

Re: 64-bit configure hell

[David Edelsohn]

	Welcome to the same hell that I encounter on AIX.  GCC will not
configure correctly on 32-bit AIX systems.

	Some solutions that I have found so far:

1) Disable 64-bit multilib when configuring on G4s.

2) Hardcode the configure values when building on 32-bit system.  In some
ways, GCC considers the configuration to be a cross-compiler.

David

Re: 64-bit configure hell

[Kaveh R. Ghazi]

 > 	    Some solutions that I have found so far:
 > 1) Disable 64-bit multilib when configuring on G4s.

Even though it's a 64-bit OS, some Solaris2.7 installations only
support 32-bit binaries, probably on older processors just like your
situation Stan.

The official solution there is to simply disable multilib during
configure just as David suggests.  See:
http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2*

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: 64-bit configure hell

[Joe Buck]

On Wed, Nov 24, 2004 at 07:20:46PM -0500, Kaveh R. Ghazi wrote:
>  > 	    Some solutions that I have found so far:
>  > 1) Disable 64-bit multilib when configuring on G4s.
> 
> Even though it's a 64-bit OS, some Solaris2.7 installations only
> support 32-bit binaries, probably on older processors just like your
> situation Stan.
> 
> The official solution there is to simply disable multilib during
> configure just as David suggests.  See:
> http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2*

How about a blacklist approach?  If we have a specific OS or processor
where we know that the answers we would otherwise get from configure about
64-bit support are wrong, it could just be flagged based on the
target triplet generated by config.guess.  In some cases config.guess
might need to be refined a bit to detect processor variants if this
isn't done already.

Certainly we can document it in install/specific.html, but it would
be nicer if ./configure, make bootstrap just works (or at least stops
with a readable error message).

Re: 64-bit configure hell

[Alexandre Oliva]

On Nov 24, 2004, David Edelsohn <dje@watson.ibm.com> wrote:

> 	Welcome to the same hell that I encounter on AIX.  GCC will not
> configure correctly on 32-bit AIX systems.

What do you mean by correctly?

> 1) Disable 64-bit multilib when configuring on G4s.

This could be done automatically, like the top-level config-ml.in is
supposed to do on aix.  Look for enable_aix64 in there and you'll
see the hack M-backspace work around.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: 64-bit configure hell

[Tom Tromey]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

Stan> This causes problems for some configure scripts, in particular
Stan> those in libstdc++ and libobjc, which want to be able to run
Stan> executables. It's not entirely clear to me why that's important,
Stan> since the libraries already build and run perfectly fine for
Stan> cross-compilers.

In the cross-compilation case target libraries make assumptions about
the target environment.  When compiling natively the configure scripts
take advantage of this and run tests instead.

Stan> Although it would be good for sales to require that people
Stan> building GCC on Darwin upgrade to G5s :-) that's kind of
Stan> unfriendly, while producing different results from configure
Stan> and make depending on one's CPU is also just asking for
Stan> trouble. What other options do I have?

Make a note about --disable-multilib somewhere?
That isn't super friendly, but it is something.

Tom

Re: 64-bit configure hell

[Stan Shebs]

Tom Tromey wrote:

>>>>>>"Stan" == Stan Shebs <shebs@apple.com> writes:
>>>>>>
> <>
> Stan> This causes problems for some configure scripts, in particular
> Stan> those in libstdc++ and libobjc, which want to be able to run
> Stan> executables. It's not entirely clear to me why that's important,
> Stan> since the libraries already build and run perfectly fine for
> Stan> cross-compilers.
>
> In the cross-compilation case target libraries make assumptions about
> the target environment. When compiling natively the configure scripts
> take advantage of this and run tests instead.

I understand how configure works - my question is why is there a
need for *execution* tests as well as compile and link tests, the
latter two being the vast majority of useful configure tests.

But I answered my own question - I simply whacked the libstdc++
test for execution, replaced with "cross_compiling=no". Multilib
libstdc++ builds just fine then, and even better, the config log
and headers look the same(!) for both the 32-bit and 64-bit cases.
So at least with libstdc++ on Darwin, I think are no execution tests
that configure actually needs to run - I think it's just autoconf
boilerplate that's there because it's convenient.

Now, how to parametrize this usefully...

Stan

Re: 64-bit configure hell

[Andrew Pinski]

On Nov 24, 2004, at 6:08 PM, Stan Shebs wrote:

> Although it would be good for sales to require that people
> building GCC on Darwin upgrade to G5s :-) that's kind of
> unfriendly, while producing different results from configure
> and make depending on one's CPU is also just asking for
> trouble. What other options do I have?

Recommend like most other targets (64bit targets) --disable-multilib.

-- Pinski

Re: 64-bit configure hell

[Daniel Jacobowitz]

On Wed, Nov 24, 2004 at 03:08:55PM -0800, Stan Shebs wrote:
> I have a messy configure problem with 64-bit Darwin, and would
> like to get some ideas about how to solve. The situation is that
> Darwin 8.x aka Tiger is capable of running 64-bit-address-space
> programs on G5s, and to support that in GCC I've set up a multilib
> for the -m64 option that enables it. This all works on G5 Tiger
> now, at least on prime-number days of the month when the moon is
> full :-) , and I hope to check in the last bits soon.
> 
> The problem is that Tiger also runs on G4s, which are not capable
> of running 64-bit programs - all the machinery is there to build
> complete and correct binaries, the kernel just refuses to execute
> them. This causes problems for some configure scripts, in particular
> those in libstdc++ and libobjc, which want to be able to run
> executables. It's not entirely clear to me why that's important,
> since the libraries already build and run perfectly fine for
> cross-compilers.
> 
> Although it would be good for sales to require that people
> building GCC on Darwin upgrade to G5s :-) that's kind of
> unfriendly, while producing different results from configure
> and make depending on one's CPU is also just asking for
> trouble. What other options do I have?

Whatever we do to solve this problem, let's try to make it general -
there are lots of affected systems.  I've seen listed so far:

  32-bit AIX
  s390-ibm-linux-gnu
  sparc-sun-solaris2.7

I also know of:
  i386-pc-solaris2.10

And I'd like to be able to enable a 64-bit multilib for:
  i386-pc-linux-gnu

For the last one, Debian hacks it using a change to config-ml.in; we
tell the other library builds that they are cross compiling if a
trivial 64-bit program can't be run.  It works for libstdc++.  It
doesn't work for libjava due to some bug I never tracked down, and it
doesn't work for libgcc (which doesn't have the execute tests problem,
but does have the problem Ulrich mentioned of not building if 64-bit
libraries are not installed).

I think moving libgcc to the top level, followed by cleaning up the
tests in config-ml.in, should be enough.  Maybe any multilib that can't
be linked should be automatically disabled, too?

-- 
Daniel Jacobowitz

Re: 64-bit configure hell

[Eric Botcazou]

> Whatever we do to solve this problem, let's try to make it general -
> there are lots of affected systems.  I've seen listed so far:
>
>   32-bit AIX
>   s390-ibm-linux-gnu
>   sparc-sun-solaris2.7

sparc-sun-solaris2.x, x>=7 to be precise.

> I also know of:
>   i386-pc-solaris2.10
>
> And I'd like to be able to enable a 64-bit multilib for:
>   i386-pc-linux-gnu

Note that this would imply HOST_WIDE_INT == long long, which probably means a 
noticeable slowdown of the compiler.  On equivalent machines (Ultra-60), the
sparc-sun-solaris2.7 compiler is roughly 20% slower than the 
sparc-sun-solaris2.6 compiler.

> For the last one, Debian hacks it using a change to config-ml.in; we
> tell the other library builds that they are cross compiling if a
> trivial 64-bit program can't be run.

The same hack is used for sparc-unknown-linux-gnu too.

-- 
Eric Botcazou