Bug 45174 - Make fails in zlib
Summary: Make fails in zlib
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.5.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-03 22:20 UTC by Donald Schlicht
Modified: 2018-04-10 04:11 UTC (History)
6 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: arm-unknown-elf
Build: arm-unknown-elf
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Script file to build arm cross compiler (2.18 KB, application/x-sh)
2010-08-03 22:22 UTC, Donald Schlicht
Details
arm-toolchain-try.sh (2.19 KB, application/x-shellscript)
2010-08-03 23:00 UTC, Donald Schlicht
Details
arm-elf log files.tar.gz (399.05 KB, application/x-compressed-tar)
2010-08-03 23:21 UTC, Donald Schlicht
Details
This one works for me (2.19 KB, text/plain)
2010-08-04 00:42 UTC, Andrew Pinski
Details
Config-logs.tar.gz (82.22 KB, application/x-compressed-tar)
2010-08-05 00:27 UTC, Donald Schlicht
Details
gcc-4.5.1_make-boot.log (1.14 KB, text/x-log)
2010-08-07 00:18 UTC, Donald Schlicht
Details
Build log and full copy of zlib and 32/zlib subdirectories in build directory (52.48 KB, application/octet-stream)
2011-01-18 01:17 UTC, John Tytgat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Donald Schlicht 2010-08-03 22:20:36 UTC
Cross compiler to arm bare metal fails during make in zlib. If configured with --with-system-zlib, make succeeds. I have an automated script which allows easier detection.
Comment 1 Donald Schlicht 2010-08-03 22:22:50 UTC
Created attachment 21382 [details]
Script file to build arm cross compiler

In line 53 commented out lines will cause make failure. Remove comments, and cross tool chain is created.
Comment 2 Andrew Pinski 2010-08-03 22:25:32 UTC
This script is broken.
Comment 3 Andrew Pinski 2010-08-03 22:28:47 UTC
The first compile of GCC should be with only C and configured with --with-newlib. And then a normal make instead of a make all-gcc. And a normal make install.
Comment 4 Donald Schlicht 2010-08-03 23:00:06 UTC
Subject: Re:  Make fails in zlib

I have made the changes requested below, however the make still fails in
zlib.

Thank You,
Donald Schlicht

On Tue, 2010-08-03 at 22:28 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #3 from pinskia at gcc dot gnu dot org  2010-08-03 22:28 -------
> The first compile of GCC should be with only C and configured with
> --with-newlib. And then a normal make instead of a make all-gcc. And a normal
> make install.
> 
> 

Comment 5 Donald Schlicht 2010-08-03 23:00:06 UTC
Created attachment 21384 [details]
arm-toolchain-try.sh
Comment 6 Andrew Pinski 2010-08-03 23:13:46 UTC
Can you provide the log of the build?
Comment 7 Donald Schlicht 2010-08-03 23:21:54 UTC
Subject: Re:  Make fails in zlib

Hello;
	Log files attached.

Thank You,
Donald Schlicht

On Tue, 2010-08-03 at 23:13 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #6 from pinskia at gcc dot gnu dot org  2010-08-03 23:13 -------
> Can you provide the log of the build?
> 
> 

Comment 8 Donald Schlicht 2010-08-03 23:21:54 UTC
Created attachment 21386 [details]
arm-elf log files.tar.gz
Comment 9 Andrew Pinski 2010-08-04 00:42:41 UTC
Created attachment 21387 [details]
This one works for me

This works for me on x86_64-linux-gnu.  I don't know what is going wrong with your build.
Comment 10 Andrew Pinski 2010-08-04 00:43:29 UTC
Can you attach all config.log files?
Comment 11 Donald Schlicht 2010-08-05 00:27:14 UTC
Subject: Re:  Make fails in zlib

Hello;
	Attached are all of the config.log files in the gcc build directory.
Please advise if you need any other files.

Thank You,
Donald Schlicht

On Wed, 2010-08-04 at 00:43 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #10 from pinskia at gcc dot gnu dot org  2010-08-04 00:43 -------
> Can you attach all config.log files?
> 
> 

Comment 12 Donald Schlicht 2010-08-05 00:27:14 UTC
Created attachment 21399 [details]
Config-logs.tar.gz
Comment 13 Ralf Wildenhues 2010-08-05 17:01:15 UTC
config.log excerpt from zlib:

configure:7903: result: yes
configure:7936: checking whether the gcc  -m64 linker (ld) supports shared libraries
configure:9020: result: yes
configure:9265: checking dynamic linker characteristics
configure:9710: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

which corresponds to this code in zlib/configure, from AC_PROG_LIBTOOL:

  lt_cv_shlibpath_overrides_runpath=no
    save_LDFLAGS=$LDFLAGS
    save_libdir=$libdir
    eval "libdir=/foo; wl=\"$lt_prog_compiler_wl\"; \
         LDFLAGS=\"\$LDFLAGS $hardcode_libdir_flag_spec\""
    if test x$gcc_no_link = xyes; then
  as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5


Either GCC or the user needs to prime cache variables in the way this test shows:
<http://git.savannah.gnu.org/cgit/libtool.git/tree/tests/no-executables.at>
(There is currently one item missing there for AIX, which is relevant for GCC but irrelevant to this particular PR).

This same issue supposedly holds for other GCC directories in which GCC_NO_EXECUTABLES is used; it might just be latent.

Question is, what values the variables should be primed with.  In general, tough one.  In this specific case: find out whether your linker sets DT_RUNPATH upon -Wl,-rpath ("yes") or only DT_RPATH ("no").  Pass lt_cv_shlibpath_overrides_runpath=no or =yes to configure accordingly.  Hmm.  How can I ensure this primes the cache for host directories only?
Comment 14 Donald Schlicht 2010-08-06 14:35:23 UTC
Subject:  Make fails in zlib

Hello;
     Can you put that in layman's terms? I am using the standard GNU
linker and assembler. I run Ubuntu 10.04 LTS with all of the latest
patches.

Thank You,
Donald Schlicht

On Thu, Aug 5, 2010 at 1:01 PM, rwild at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #13 from rwild at gcc dot gnu dot org  2010-08-05 17:01 -------
> config.log excerpt from zlib:
>
> configure:7903: result: yes
> configure:7936: checking whether the gcc  -m64 linker (ld) supports shared
> libraries
> configure:9020: result: yes
> configure:9265: checking dynamic linker characteristics
> configure:9710: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
>
> which corresponds to this code in zlib/configure, from AC_PROG_LIBTOOL:
>
>  lt_cv_shlibpath_overrides_runpath=no
>    save_LDFLAGS=$LDFLAGS
>    save_libdir=$libdir
>    eval "libdir=/foo; wl=\"$lt_prog_compiler_wl\"; \
>         LDFLAGS=\"\$LDFLAGS $hardcode_libdir_flag_spec\""
>    if test x$gcc_no_link = xyes; then
>  as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
> 5
>
>
> Either GCC or the user needs to prime cache variables in the way this test
> shows:
> <http://git.savannah.gnu.org/cgit/libtool.git/tree/tests/no-executables.at>
> (There is currently one item missing there for AIX, which is relevant for GCC
> but irrelevant to this particular PR).
>
> This same issue supposedly holds for other GCC directories in which
> GCC_NO_EXECUTABLES is used; it might just be latent.
>
> Question is, what values the variables should be primed with.  In general,
> tough one.  In this specific case: find out whether your linker sets DT_RUNPATH
> upon -Wl,-rpath ("yes") or only DT_RPATH ("no").  Pass
> lt_cv_shlibpath_overrides_runpath=no or =yes to configure accordingly.  Hmm.
> How can I ensure this primes the cache for host directories only?
Comment 15 Ralf Wildenhues 2010-08-06 17:22:01 UTC
(In reply to comment #14)
>      Can you put that in layman's terms?

Yes; sorry for the complicated and technical response.  As far as I can see, there is at the moment no simple way to avoid this issue with a configure command-line switch, so I'll describe an approach that hopefully works around the issue for now:

In the build tree where the error occurred, there should be an empty file named something like:

  arm-unknown-elf/zlib/config.cache

Please open that file with a text editor and add the line

  lt_cv_shlibpath_overrides_runpath=no

Then rerun make.  Please report back if that works or not; if it doesn't, then find the first error message in the output and cut and paste 50 lines of output from a few lines above that error message. Thanks.

I'll write to the gcc list about how to improve configury so that this hopefully becomes easier or unnecessary in the future.
Comment 16 Donald Schlicht 2010-08-07 00:18:33 UTC
Subject: Re:  Make fails in zlib

Hello;
	I changed the value of lt_cv_shlibpath_overrides_runpath (it was set to
the result of an equality statement). No joy. The log is attached.
Results from the terminal are:

donald@donald-desktop:~$  sh Try15.sh /home/donald arm-elf 5
Found Linux OS.
******************************************************************
* Building gcc-4.5.1-boot
******************************************************************
make[3]: *** No rule to make target `all'.  Stop.
make[2]: *** [multi-do] Error 1
make[1]: *** [all-multi] Error 2
make: *** [all-zlib] Error 2
make: *** Waiting for unfinished jobs....
donald@donald-desktop:~$ 

	Previously to placing this bug report, I tried to find the source of
the error. The error occurs in this piece of code from configure in the
zlib source directory:

if test "${lt_cv_ld_exported_symbols_list+set}" = set; then :
  $as_echo_n "(cached) " >&6
else
  lt_cv_ld_exported_symbols_list=no
      save_LDFLAGS=$LDFLAGS
      echo "_main" > conftest.sym
      LDFLAGS="$LDFLAGS -Wl,-exported_symbols_list,conftest.sym"
      if test x$gcc_no_link = xyes; then
  as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES."
"$LINENO" 5
fi

This piece of code is executed twice, first with
lt_cv_ld_exported_symbols_list set to blank, and gcc_no_link set to
blank. lt_cv_ld_exported_symbols_list is set to no because the else part
of the if statement is executed. Because gcc_no_link is not set, no
error is triggered.

However on the second pass, lt_cv_ld_exported_symbols_list has lost its
value (is blank), however gcc_no_link is set to yes. Result error. I
have not found out why lt_cv_ld_exported_symbols_list loses its value on
the second pass. LDFLAGS also loses its value on the second pass.

Thank You,
Donald Schlicht

Comment 17 Donald Schlicht 2010-08-07 00:18:33 UTC
Created attachment 21430 [details]
gcc-4.5.1_make-boot.log
Comment 18 Ralf Wildenhues 2010-08-07 14:29:29 UTC
Please do the following for me in your toplevel build directory, thanks:
  tar cvf config-logs.tar `find . -name config.log -o -name config.cache`
  gzip config-logs.tar

and attach the tarball to this issue.
Comment 19 Donald Schlicht 2010-08-08 19:19:17 UTC
Subject: Re:  Make fails in zlib

Hello;
	I am afraid I messed up my system. I was playing around trying to
install the latest versions of binutils and gcc on my linux system
(native, not cross compile), and now I am getting a different error. In
zlib's config.log:

ne=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) 
configure:3234: $? = 0
configure:3223: gcc  -m64 -V >&5
gcc: '-V' must come at the start of the command line
configure:3234: $? = 1
configure:3223: gcc  -m64 -qversion >&5
gcc: unrecognized option '-qversion'
gcc: no input files
configure:3234: $? = 1
configure:3250: gcc  -m64 -o conftest -g -O2    conftest.c  >&5
Assembler messages:
Fatal error: No compiled in support for x86_64
configure:3253: $? = 1
configure:3441: checking for suffix of object files
configure:3463: gcc  -m64 -c -g -O2  conftest.c >&5
Assembler messages:
Fatal error: No compiled in support for x86_64
configure:3467: $? = 1

It looks like configure is trying to compile sources to 64 bit. I am
running a 32 bit system. Any ideas on how to tell configure to compile
for a 32 bit linux box?

Thank You,
Donald Schlicht

Comment 20 Ralf Wildenhues 2010-08-08 20:44:02 UTC
(In reply to comment #19)
>         I am afraid I messed up my system. I was playing around trying to
> install the latest versions of binutils and gcc on my linux system
> (native, not cross compile), and now I am getting a different error. In
> zlib's config.log:
> 
> ne=generic --enable-checking=release --build=i486-linux-gnu
> --host=i486-linux-gnu --target=i486-linux-gnu

You are not cross-building for arm-unknown-elf any more, so the error you are getting has nothing to do with this PR any more.  Please get your system in order first, I cannot help you with that, and I'm afraid people working on GCC PRs don't really have the resources to help with that.  Their primary interest is in fixing GCC.  I think this PR is probably valid but don't have the resources to confirm myself.

If you want to create a native compiler on x86-linux, try disabling multilibs as documented in the installation manual (and please follow up on the gcc-help list if you have questions regarding that).
Comment 21 Donald Schlicht 2010-08-09 00:42:46 UTC
Subject: Re:  Make fails in zlib

Hello;
	Well I solved my problem, however the issue still remains. I installed
the latest native binutils and gcc-4.5.1 on my linux installation. The
script now works without any errors.

	However it appears that using the supplied binutils and compilers from
Ubuntu 10.04 there is a problem creating the cross compilers. I do not
know how or if I should proceed from here. It maybe there there is some
subtle error in the bins supplied with Ubuntu.

Thank You,
Donald Schlicht

Comment 22 Ian Bolton 2010-09-07 14:44:06 UTC
(In reply to comment #21)
> Subject: Re:  Make fails in zlib
> 
> Hello;
>         Well I solved my problem, however the issue still remains. I installed
> the latest native binutils and gcc-4.5.1 on my linux installation. The
> script now works without any errors.
> 
>         However it appears that using the supplied binutils and compilers from
> Ubuntu 10.04 there is a problem creating the cross compilers. I do not
> know how or if I should proceed from here. It maybe there there is some
> subtle error in the bins supplied with Ubuntu.
> 
> Thank You,
> Donald Schlicht
> 

I've just read this thread and am now unsure as to whether there is a bug with GCC or not.  It sounds like your initial troubles have gone away and now there is a new problem.  Would it make sense to close this bug and raise a new bug to cover the new issue?

Comment 23 Ian Bolton 2010-09-08 10:06:01 UTC
(In reply to comment #21)
> Subject: Re:  Make fails in zlib
> 
> Hello;
>         Well I solved my problem, however the issue still remains. I installed
> the latest native binutils and gcc-4.5.1 on my linux installation. The
> script now works without any errors.
> 
>         However it appears that using the supplied binutils and compilers from
> Ubuntu 10.04 there is a problem creating the cross compilers. I do not
> know how or if I should proceed from here. It maybe there there is some
> subtle error in the bins supplied with Ubuntu.
> 
> Thank You,
> Donald Schlicht
> 

I've just read this thread and am now unsure as to whether there is a bug with GCC or not.  It sounds like your initial troubles have gone away and now there is a new problem.  Would it make sense to close this bug and raise a new bug to cover the new issue?

Comment 24 Ralf Wildenhues 2010-09-08 16:26:59 UTC
(In reply to comment #22)
> I've just read this thread and am now unsure as to whether there is a bug with
> GCC or not.  It sounds like your initial troubles have gone away and now there
> is a new problem.  Would it make sense to close this bug and raise a new bug to
> cover the new issue?

It would make sense to treat any issues that Donald has in a new PR (after making sure they are not setup problems).

However, I am fairly sure that comment #13 describes a real issue, as it has been reported to Libtool before, and there is a Libtool testsuite addition that exposes link tests in AC_PROG_LIBTOOL that are not guarded by a cache variable.

The issue described by #13 may be latent in GCC.  I haven't tried to reproduce it there yet.
Comment 25 Ralf Wildenhues 2010-10-02 14:52:12 UTC
Author: rwild
Date: Sat Oct  2 14:52:07 2010
New Revision: 164904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164904
Log:
Allow to pass separate configure arguments for build, host and target.

/:
	PR bootstrap/45326
	PR bootstrap/45174
	* configure.ac: Honor initial values of $build_configargs,
	$host_configargs, $target_configargs.  Mark the precious, so
	environment settings get recorded.
	* configure: Regenerate.

gcc/:
	* doc/install.texi (Configuration): Document build_configargs,
	host_configargs, target_configargs.

Modified:
    trunk/ChangeLog
    trunk/configure
    trunk/configure.ac
    trunk/gcc/ChangeLog
    trunk/gcc/doc/install.texi
Comment 26 John Tytgat 2011-01-18 01:15:57 UTC
I'm seeing the same problem with gcc 4.6 trunk (r168937) for building a cross compiler with target arm-unknown-eabi configured with newlib in tree.  The crucial bit is --enable-multilib, without this option the problem is not reproducible.

It looks like the --enable-multilib enables building the multilibs of the host (instead of the target) for zlib.  In my case the host is (on Ubuntu 10.04):

$ gcc -dumpmachine
x86_64-linux-gnu
$ gcc -print-multi-lib
.;
32;@m32

I've attached my buildlog and the full content of gcc builddir subdirectories 'zlib' and '32/zlib' (the latter not present when --enable-multilib is omitted).

Also like the original bug reporter is saying: I can avoid this problem by specifying --with-system-zlib.
Comment 27 John Tytgat 2011-01-18 01:17:29 UTC
Created attachment 23009 [details]
Build log and full copy of zlib and 32/zlib subdirectories in build directory
Comment 28 Ralf Wildenhues 2011-01-18 07:10:48 UTC
(In reply to comment #26)
> I'm seeing the same problem with gcc 4.6 trunk (r168937) for building a cross
> compiler with target arm-unknown-eabi configured with newlib in tree.  The
> crucial bit is --enable-multilib, without this option the problem is not
> reproducible.

You shouldn't ever need to pass --enable-multilib explicitly to toplevel configure, as multilib is enabled by default.  On top of that, there is a bug currently in that explicit --enable-multilib is handled wrongly, see PR 43328.
Comment 29 Donald Schlicht 2011-04-12 19:36:43 UTC
I found that there is a problem with the gcc compiler that shipps with
Ubuntu. If you build the gcc compiler from scratch for Linux, then the
build for the arm works.
Comment 30 Eric Gallager 2017-10-10 23:39:50 UTC
Is there a reason this bug is still in WAITING?
Comment 31 Eric Gallager 2018-04-10 04:11:54 UTC
(In reply to Eric Gallager from comment #30)
> Is there a reason this bug is still in WAITING?

No response; I'm going to close this.