[Bug bootstrap/45174] Make fails in zlib

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #31 from Eric Gallager  ---
(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.

[Bug bootstrap/45174] Make fails in zlib

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #30 from Eric Gallager  ---
Is there a reason this bug is still in WAITING?

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

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

--- Comment #29 from 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.

[Bug bootstrap/45174] Make fails in zlib

[rwild at gcc dot gnu.org]

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

--- Comment #28 from 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.

[Bug bootstrap/45174] Make fails in zlib

[John.Tytgat at aaug dot net]

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

--- Comment #27 from John Tytgat  2011-01-18 
01:17:29 UTC ---
Created attachment 23009
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23009
Build log and full copy of zlib and 32/zlib subdirectories in build directory

[Bug bootstrap/45174] Make fails in zlib

[John.Tytgat at aaug dot net]

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

John Tytgat  changed:

   What|Removed |Added

 CC||John.Tytgat at aaug dot net

--- Comment #26 from 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.

[Bug bootstrap/45174] Make fails in zlib

[rwild at gcc dot gnu.org]

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

--- Comment #25 from 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

[Bug bootstrap/45174] Make fails in zlib

[rwild at gcc dot gnu dot org]

--- Comment #24 from rwild at gcc dot gnu dot org  2010-09-08 16:26 ---
(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.


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[ibolton at gcc dot gnu dot org]

--- Comment #23 from ibolton at gcc dot gnu dot org  2010-09-08 10:06 
---
(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?


-- 

ibolton at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ibolton at gcc dot gnu dot
   ||org


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

[Bug bootstrap/45174] Make fails in zlib

[ibolton at gcc dot gnu dot org]

--- Comment #22 from ibolton at gcc dot gnu dot org  2010-09-07 14:44 
---
(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?


-- 

ibolton at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #21 from dschlic1 at gmail dot com  2010-08-09 00:42 ---
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


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[rwild at gcc dot gnu dot org]

--- Comment #20 from rwild at gcc dot gnu dot org  2010-08-08 20:44 ---
(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).


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #19 from dschlic1 at gmail dot com  2010-08-08 19:19 ---
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 -O2conftest.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


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[rwild at gcc dot gnu dot org]

--- Comment #18 from rwild at gcc dot gnu dot org  2010-08-07 14:29 ---
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.


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #16 from dschlic1 at gmail dot com  2010-08-07 00:18 ---
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:

don...@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
don...@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 from dschlic1 at gmail dot com  2010-08-07 00:18 ---
Created an attachment (id=21430)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21430&action=view)


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[rwild at gcc dot gnu dot org]

--- Comment #15 from rwild at gcc dot gnu dot org  2010-08-06 17:22 ---
(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.


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #14 from dschlic1 at gmail dot com  2010-08-06 14:35 ---
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
 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:
> 
> (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?


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[rwild at gcc dot gnu dot org]

--- 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:

(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?


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #11 from dschlic1 at gmail dot com  2010-08-05 00:27 ---
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 +, 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 from dschlic1 at gmail dot com  2010-08-05 00:27 ---
Created an attachment (id=21399)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21399&action=view)


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2010-08-04 00:43 
---
Can you attach all config.log files?


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2010-08-04 00:42 ---
Created an attachment (id=21387)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21387&action=view)
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.


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #7 from dschlic1 at gmail dot com  2010-08-03 23:21 ---
Subject: Re:  Make fails in zlib

Hello;
Log files attached.

Thank You,
Donald Schlicht

On Tue, 2010-08-03 at 23:13 +, 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 from dschlic1 at gmail dot com  2010-08-03 23:21 ---
Created an attachment (id=21386)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21386&action=view)


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-08-03 23:13 ---
Can you provide the log of the build?


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #4 from dschlic1 at gmail dot com  2010-08-03 23:00 ---
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 +, 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 from dschlic1 at gmail dot com  2010-08-03 23:00 ---
Created an attachment (id=21384)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21384&action=view)


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[pinskia at gcc dot gnu dot org]

--- 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.


-- 


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

[Bug bootstrap/45174] Make fails in zlib

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-08-03 22:25 ---
This script is broken.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet| i686-pc-linux-gnu  |i686-pc-linux-gnu


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #1 from dschlic1 at gmail dot com  2010-08-03 22:22 ---
Created an attachment (id=21382)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21382&action=view)
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.


-- 


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