[Bug other/56780] --disable-install-libiberty still installs libiberty.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Eric Gallager --- (In reply to Mike Frysinger from comment #9) > http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00213.html has been committed > now which should fix trunk Assuming the fix was successful; closing
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 knrstaj at gmail dot com changed: What|Removed |Added CC||knrstaj at gmail dot com --- Comment #8 from knrstaj at gmail dot com --- --enable-install-libiberty will not install header and lib. Because in configure.ac target_header_dir will be clean at line 414 target_header_dir should be move together with svn commit 199570
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 --- Comment #9 from Mike Frysinger vapier at gentoo dot org --- http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00213.html has been committed now which should fix trunk
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Ingo Müller 2013.bugzilla.gcc.gnu.org at ingomueller dot net changed: What|Removed |Added CC||2013.bugzilla.gcc.gnu.org@i ||ngomueller.net --- Comment #7 from Ingo Müller 2013.bugzilla.gcc.gnu.org at ingomueller dot net --- libiberty.a is still installed to /lib/libiberty.a in GCC 4.8.1, even with --disable-install-libiberty set.
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Pedro Alves palves at redhat dot com changed: What|Removed |Added CC||palves at redhat dot com --- Comment #4 from Pedro Alves palves at redhat dot com --- I believe the fix has been checked in, right?
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Yaakov (Cygwin Ports) yselkowitz at users dot sourceforge.net changed: What|Removed |Added CC||yselkowitz at users dot sourceforg ||e.net --- Comment #5 from Yaakov (Cygwin Ports) yselkowitz at users dot sourceforge.net --- An unfortunate (and presumably unintended) consequence of this commit was that libiberty.a is no longer installed by default when building binutils CVS HEAD either. As libbfd and libopcodes still require its symbols, and both are built static-only by default, this change renders those libraries unusable. AFAICS another step is needed in the top-level configury to pass --enable-install-libiberty when bfd/opcodes is being built.
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 --- Comment #6 from Yaakov (Cygwin Ports) yselkowitz at users dot sourceforge.net --- Not only that, but even with --enable-install-libiberty, it's not being installed in CVS HEAD. Don't you need to remove the resetting of target_header_dir in libiberty/configure.ac:408 (and hence libiberty/configure:5510)?
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 --- Comment #3 from Matthew Burgess matthew at linuxfromscratch dot org --- (In reply to Jonathan Wakely from comment #2) I suggest pinging the gcc-patches list about your patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00167.html and CC Ian as he is a maintainer for libiberty and he agreed on the gcc list that this is a bug. Thanks for the reminder, Jonathan. Pinged yesterday, including Ian on the CC list. The archived email is at http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00664.html.
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-13 CC||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Hi, thanks for trying to fix this. I need this switch to work too, otherwise the non-PIC libiberty.a from my GCC installation conflicts with my distro's PIC /usr/lib64/libiberty.a and prevents me linking shared libraries with -lbfd I suggest pinging the gcc-patches list about your patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00167.html and CC Ian as he is a maintainer for libiberty and he agreed on the gcc list that this is a bug.
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 --- Comment #1 from Matthew Burgess matthew at linuxfromscratch dot org 2013-04-03 14:04:34 UTC --- Created attachment 29795 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29795 Patch to handle --disable-install-libiberty correctly
