[Bug other/56780] New: --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Bug #: 56780 Summary: --disable-install-libiberty still installs libiberty.a Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: matt...@linuxfromscratch.org I'd like to build GCC with --disable-install-libiberty so that the version of libiberty.a provided by Binutils that is already installed will not be overwritten. However, the libiberty.a library is still installed even with that flag specified. My full configure invocation (run from within ~/gcc-build) is: ../gcc-4.8.0-version;/configure --prefix=/usr \ --libexecdir=/usr/lib \ --enable-shared \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-clocale=gnu\ --enable-languages=c,c++\ --disable-multilib \ --disable-bootstrap \ --disable-install-libiberty \ --with-system-zlib Additionally, libiberty's configure script's help output states: ' --enable-install-libiberty Install headers for end users' For clarity, that should probably read: 'Install headers and static library for end users'. That way, it's in agreement with what is also mentioned in libiberty.texi. Thanks, Matt.
[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 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
[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 --- (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 c++/14172] g++ should not emit effc++ warnings in system headers
--- Additional Comments From matthew at linuxfromscratch dot org
2004-11-19 07:51 ---
Putting trivial test cases together, both with and without #pragma GCC
system_header in them, the compiler behaves correctly. Compiling the test case
in comment 1 shows results in 24 lines of warnings, none of which the user can
do anything about, as they all relate to the _internal_ headers in
/usr/include/c++/${gcc-version}/bits. So, system headers appear to be treated
correctly (e.g. has the #pragma GCC system_header), but why are the
headers in bits/ not treated as system headers? Neither adding the pragma to
those headers, nor adding "-isystem /usr/include/c++/${gcc-version}/bits" to the
command line appeared to have any effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14172
[Bug c++/14172] g++ should not emit effc++ warnings in system headers
--- Additional Comments From matthew at linuxfromscratch dot org 2004-11-23 10:18 --- Would someone mind commenting on what needs to happen with this bug please? My testing has shown that the behaviour of -Weffc++ is correct with regard to system headers. The problem is that some of the headers in /usr/include/c++/$gcc-version/bits aren't treated as system headers. This doesn't just affect -Weffc++, it actually affects *all* warning options (e.g. -Wunreachable-code is often triggered by such headers IIRC). Does the bug summary need changing? What about the component? (I suspect this is now in the realm of libstdc++). It seems closely related to bug 12854. Thanks, Matt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14172
