Build problem with 4.8.0 RC-20130316 and in-tree binutils
Hi all,
I'm having trouble building the RC 4.8.0 with an in-tree binutils on
an Ubuntu 12.04 x86_64. It seems that while building GCC, the runtime
library path does not include the objdir/prev-*/.libs directories; so
whenever any of the built binutils programs are run they fail as their
shared libraries cannot be found. The SOs are built but aren't on the
LD_LIBRARY_PATH it seems.
For example, configure of the "intl" package fails with
/home/mgodbolt/dev/fig-packages/scratch/gcc/4.8.0-RC-20130316/objdir/prev-gas/.libs/lt-as-new:
error while loading shared libraries:libopcodes-2.23.1.so: cannot open
shared object file: No such file or directory
But binutils has been successfully built earlier by the gcc makefile,
and is available:
wud-mgodbolt01:~/dev/fig-packages/scratch/gcc/4.8.0-RC-20130316/objdir(master)⚡
mgodbolt$ find -name libopcodes-2.23.1.so
./prev-opcodes/.libs/libopcodes-2.23.1.so
I was able to successfully built GCC 4.7.2 with in-tree binutils.
I'm using BINUTILS 2.23.1 (though have tried 2.22 with the same
issue), and the following configure options:
--prefix=/site/apps/gcc-4.8.0-RC-20130316
--build=x86_64-linux-gnu
--enable-clocale=gnu
--enable-languages=c,c++
--enable-ld=yes
--enable-libstdcxx-debug
--enable-libstdcxx-time=yes
--enable-linker-build-id
--enable-lto
--enable-plugin
--enable-shared
--enable-threads=posix
--host=x86_64-linux-gnu
--target=x86_64-linux-gnu
--with-system-zlib
I configure from an object directory just above the root of gcc, and I
prepare the merged tree by symbolically linking all binutils files and
directories out of the binutils package into gcc (unless they are
already present):
BINUTILS_DIR=binutils-${BINUTILS_VERSION}
BINUTILS_FILES=$(cd ${BINUTILS_DIR}; ls -1)
pushd gcc-${VERSION}
for file in ${BINUTILS_FILES}
do
if [ ! -e "$file" ]
then
ln -sf "../${BINUTILS_DIR}/${file}"
fi
done
popd
Any pointers welcomed, and I'd be happy to supply even more information.
Much appreciated, Matt
Re: Build problem with 4.8.0 RC-20130316 and in-tree binutils
On Wed, Mar 20, 2013 at 5:35 AM, Matt Godbolt wrote: > > I'm having trouble building the RC 4.8.0 with an in-tree binutils on > an Ubuntu 12.04 x86_64. It seems that while building GCC, the runtime > library path does not include the objdir/prev-*/.libs directories; so > whenever any of the built binutils programs are run they fail as their > shared libraries cannot be found. The SOs are built but aren't on the > LD_LIBRARY_PATH it seems. I'm pretty sure that the GCC build never added bfd/.libs or opcodes/.libs to LD_LIBRARY_PATH. > --enable-shared Are you sure that you used --enable-shared when building GCC 4.7 with an in-tree binutils? That is what is causing your problem; building the binutils with --enable-shared is causing them to use a shared libbfd and libopcodes, leading to the failure. Is it possible that the behaviour of --enable-shared has changed for the binutils? Or is it possible that you have an installed libbfd.so and libopcodes.so, but not one that is new enough for the in-tree binutils you are building? Ian
Re: Build problem with 4.8.0 RC-20130316 and in-tree binutils
Hi Ian, Thanks for the quick reply. I definitely have --enable-shared set in the configuration, and had so with 4.7. However I'm not certain that previously a system-installed libbfd.so et al were causing my build to succeed (for the wrong reason). I'll try a build without --enable-shared and see if that works. What does this flag do: I couldn't find any reference to it on http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html or in ./configure --help - I must have picked it up from the seed set of configure options I cribbed from the Ubuntu-built gcc. Thanks, Matt On Wed, Mar 20, 2013 at 8:18 AM, Ian Lance Taylor wrote: > On Wed, Mar 20, 2013 at 5:35 AM, Matt Godbolt wrote: >> >> I'm having trouble building the RC 4.8.0 with an in-tree binutils on >> an Ubuntu 12.04 x86_64. It seems that while building GCC, the runtime >> library path does not include the objdir/prev-*/.libs directories; so >> whenever any of the built binutils programs are run they fail as their >> shared libraries cannot be found. The SOs are built but aren't on the >> LD_LIBRARY_PATH it seems. > > I'm pretty sure that the GCC build never added bfd/.libs or > opcodes/.libs to LD_LIBRARY_PATH. > >> --enable-shared > > Are you sure that you used --enable-shared when building GCC 4.7 with > an in-tree binutils? That is what is causing your problem; building > the binutils with --enable-shared is causing them to use a shared > libbfd and libopcodes, leading to the failure. > > Is it possible that the behaviour of --enable-shared has changed for > the binutils? > > Or is it possible that you have an installed libbfd.so and > libopcodes.so, but not one that is new enough for the in-tree binutils > you are building? > > Ian -- Matt
Re: Build problem with 4.8.0 RC-20130316 and in-tree binutils
On Wed, Mar 20, 2013 at 6:36 AM, Matt Godbolt wrote: > > Thanks for the quick reply. I definitely have --enable-shared set in > the configuration, and had so with 4.7. However I'm not certain that > previously a system-installed libbfd.so et al were causing my build to > succeed (for the wrong reason). > > I'll try a build without --enable-shared and see if that works. What > does this flag do: I couldn't find any reference to it on > http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html or in > ./configure --help - I must have picked it up from the seed set of > configure options I cribbed from the Ubuntu-built gcc. The --enable-shared option is the default for GCC. The libstdc++ manual only lists the configure options that are specific to libstdc++, as it says in the second paragraph on the web page you cite. The --enable-shared option for GCC is documented at http://gcc.gnu.org/install/configure.html . The --enable-shared option is not the default for the various binutils. Using --enable-shared when building the binutils causes them to use a shared libbfd and libopcodes. This is documented in binutils/README. When using an in-tree build you get a mix of the GCC and binutils configure options. This approach must be used with care. Ian
Re: Build problem with 4.8.0 RC-20130316 and in-tree binutils
On Wed, Mar 20, 2013 at 8:42 AM, Ian Lance Taylor wrote: > On Wed, Mar 20, 2013 at 6:36 AM, Matt Godbolt wrote: >> >> Thanks for the quick reply. I definitely have --enable-shared set in >> the configuration, and had so with 4.7. However I'm not certain that >> previously a system-installed libbfd.so et al were causing my build to >> succeed (for the wrong reason). >> >> I'll try a build without --enable-shared and see if that works. What >> does this flag do: I couldn't find any reference to it on >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html or in >> ./configure --help - I must have picked it up from the seed set of >> configure options I cribbed from the Ubuntu-built gcc. > > The --enable-shared option is the default for GCC. > > The libstdc++ manual only lists the configure options that are > specific to libstdc++, as it says in the second paragraph on the web > page you cite. The --enable-shared option for GCC is documented at > http://gcc.gnu.org/install/configure.html . > > The --enable-shared option is not the default for the various > binutils. Using --enable-shared when building the binutils causes > them to use a shared libbfd and libopcodes. This is documented in > binutils/README. > > When using an in-tree build you get a mix of the GCC and binutils > configure options. This approach must be used with care. > > Ian Thanks once again. It sounds like an in-tree build of binutils is not recommended. I will look into building it outside of GCC if I encounter any further problems. So far the GCC build is still running without issue and has gotten past its previous fail point. Best regards, Matt
New cilkplus-merge branch
Hi folks. In order to facilitate the contribution and possible merging of the cilkplus work into mainline, I have created a new git branch (cilkplus-merge). I have also created a wiki page where we (Balaji and myself) will keep a status of the work: http://gcc.gnu.org/wiki/cilkplus-merge I have also linked this wiki entry from our main wiki, adding it as an ongoing project: http://gcc.gnu.org/wiki/ The goal of this branch (as opposed to the cilkplus-branch where Balaji has been working on), is to serve as a staging area for work being contributed for review. My goal is to only put things that are being submitted for review, and are independently testable, etc. As such, the branch only contains the array notation work, to make it easier for the reviewers (ok, Joseph in this case :-)), to look at independent chunks. After this is in an acceptable condition, perhaps we can merge it into trunk, and then move onto the rest of the items as listed in the wiki. Basically, the order of submission/review/contribution is tentatively set as: - array notation (AWAITING REVIEW) - #pragma simd - elemental functions - cilkplus keywords - cilk_spawn - cilk_sync - cilk_for - runtime In a separate mail to gcc-patches I will include the latest, tested patchset for the array notation work for review, and as of now, the only code in the branch (independent of anything else cilkplus). Please let me or Balaji know if you have any suggestions, or if we can change our plan of attack to aid in review. Thanks. Aldy
