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.
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.
This script is broken.
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.
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. > >
Created attachment 21384 [details] arm-toolchain-try.sh
Can you provide the log of the build?
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? > >
Created attachment 21386 [details] arm-elf log files.tar.gz
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.
Can you attach all config.log files?
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? > >
Created attachment 21399 [details] Config-logs.tar.gz
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?
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?
(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.
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
Created attachment 21430 [details] gcc-4.5.1_make-boot.log
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.
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
(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).
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
(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?
(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.
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
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.
Created attachment 23009 [details] Build log and full copy of zlib and 32/zlib subdirectories in build directory
(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.
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.
Is there a reason this bug is still in WAITING?
(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.