Fix build regression in commit 18fae96

Fix build regression in commit 18fae96

Commit 18fae96 broke the build with a GCC_NO_EXECUTABLES configure
complaint because it introduced a linking test, which is not allowed.

This redoes that change so it does not overload the native Linux version
and take in its linking test.  The test in question is to determine
whether default linking is behaving as under --enable-new-dtags.
The answer is no with our binutils.

BUG=http://code.google.com/p/nativeclient/issues/detail?id=1580
TEST='make build-with-newlib' now works

R=halyavin@google.com,khim@google.com

Committed: http://git.chromium.org/gitweb/?p=nacl-gcc.git;a=commit;h=058ec16

[halyavin, 2011-04-07 08:09:03]

On 2011/04/07 00:59:35, Roland McGrath wrote:

LGTM. I checked that both glibc and newlib (make dev-build
TOOLCHAINLOC=/path/to/result) compile successfully.

[pasko-google - do not use, 2011-04-07 11:51:17]

Roland,

Your change looks cleaner to me than Andrey's.  However, I want to understand
why we need to define these variables before commit:
shlibpath_var, shlibpath_overrides_runpath, hardcode_into_libs

I successfully built the newlib toolchain on my lucid64 machine with:
shell> make build-with-newlib -j16
(prepared native_client/tools/SRC by running 'make sync' and making local
changes if necessary, and rm -rf BUILD)

I reproduced the newlib build failure on modular-build trybots:
hecking whether the
/mnt/data/b/build/slave/nacl-modular-toolchain-64/build/native_client/tools/modular-build/out/build/full-gcc/./gcc/xgcc
[...] linker ([...]/collect-ld) supports shared libraries... yes
checking dynamic linker characteristics... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.

Victor's idea why it works with the Makefile is because libnacl.a (and
startfiles) is created prior to running the GCC build, so GCC can actually link
the test above.  This seemed to be necessary for enabling Fortran (that we
disabled later by other reasons:)

P.S.: modular-build is solely a 20% project of Mark Seaborn, take it with a
grain of salt

[halyavin, 2011-04-07 12:34:14]

My investigation showed that glibc compiles if just library_names_spec and
soname_spec are set. So other assigments should be removed.

[Use chromium.org instead, 2011-04-07 17:00:09]

libtool.m4 is used for building libstdc++, not glibc.

The other settings are accurate for our toolchain, which is the same as
native Linux for all these issues.
Getting these details wrong can lead to building libstdc++.so successfully
but with subtle errors that will show up in hairy circumstances eventually.

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[Use chromium.org instead, 2011-04-07 17:30:42]

In fact, libtool.m4 is also used for building libgcc, which is where we had
the failure.
libgcc/configure.ac uses GCC_NO_EXECUTABLES unconditionally, which disallows
ALL link-time tests for the build of libgcc.
So I cannot see how a gcc build worked correctly, since all builds should be
building the target libgcc.

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[Roland McGrath, 2011-04-07 17:48:41]

BTW, I got my local build problem worked out.  Somehow I had local
tools/BUILD/stamp-nacl{64,}-binutils but the binutils builds had not fully
populated out/nacl-sdk/bin with symlinks nacl64-as et al.  Wiping and refreshing
the binutils builds got those in place and now the pregcc build is happy (with
my change).

[khim, 2011-04-07 19:45:57]

Actually I like this change (it's closer to upstream way of doing things), I
just don't like the description: it's cleanup change, not build-fixing change.

As for shlibpath_var, shlibpath_overrides_runpath and hardcode_into_libs...
We'll want to revisit this part when we'll have at least some understanding
about how GLibC will work in browser. For now we can use Linux values - they
reflect our current state of GLibC. When and if we'll change the GLibC we'll
review this part again.