[Bug c/55915] New: fails to build lto-compress.c, zlib.h not found

[Bug c/55915] New: fails to build lto-compress.c, zlib.h not found

[alexpux at gmail dot com]

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

             Bug #: 55915
           Summary: fails to build lto-compress.c, zlib.h not found
    Classification: Unclassified
           Product: gcc
           Version: lto
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: alexpux@gmail.com


I have trouble with building GCC from trunk with system zlib. My configure line
is:
configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 
--prefix=/temp/x64-trunk-snapshot-posix-seh-rev3/prefix 
--with-sysroot=/temp/x64-trunk-snapshot-posix-seh-rev3/prefix 
--enable-shared --enable-static --disable-multilib 
--enable-languages=c,c++,fortran,lto 
--enable-libstdcxx-time=yes 
--enable-threads=posix 
--enable-libgomp 
--enable-lto 
--enable-graphite 
--enable-cloog-backend=isl
--enable-checking=release 
--enable-fully-dynamic-string 
--enable-version-specific-runtime-libs 
--disable-ppl-version-check 
--disable-cloog-version-check 
--disable-libstdcxx-pch 
--disable-libstdcxx-debug 
--disable-bootstrap 
--disable-rpath 
--disable-win32-registry 
--disable-nls 
--disable-werror 
--disable-symvers 
--with-gnu-as 
--with-gnu-ld 
--with-arch=nocona --with-tune=core2 
--with-host-libstdcxx=-static -lstdc++ 
--with-libiconv
 --with-system-zlib 
--with-gmp=/temp/mingw-prereq/x86_64-w64-mingw32-static 
--with-mpfr=/temp/mingw-prereq/x86_64-w64-mingw32-static
--with-mpc=/temp/mingw-prereq/x86_64-w64-mingw32-static 
--with-ppl=/temp/mingw-prereq/x86_64-w64-mingw32-static 
--with-cloog=/temp/mingw-prereq/x86_64-w64-mingw32-static 
--with-pkgversion=Built by MinGW-builds project 
--with-bugurl=http://sourceforge.net/projects/mingwbuilds/ 
CFLAGS=-O2 -pipe -fomit-frame-pointer
-I/temp/x64-trunk-snapshot-posix-seh-rev3/libs/include
-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include
-I/temp/mingw-prereq/x64-zlib/include 
CXXFLAGS=-O2 -pipe -fomit-frame-pointer 
CPPFLAGS= 
LDFLAGS=-pipe -L/temp/x64-trunk-snapshot-posix-seh-rev3/libs/lib
-L/temp/mingw-prereq/x86_64-w64-mingw32-static/lib
-L/temp/x64-trunk-snapshot-posix-seh-rev3/prefix/opt/lib
-L/temp/mingw-prereq/x64-zlib/lib

I have prebuilded zlib in /temp/mingw-prereq/x64-zlib.
During build I nave error:

x86_64-w64-mingw32-g++ -c   -O2 -pipe -fomit-frame-pointer -DIN_GCC  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../../../mingw-sources/gcc-trunk/gcc
-I../../../../mingw-sources/gcc-trunk/gcc/.
-I../../../../mingw-sources/gcc-trunk/gcc/../include
-I../../../../mingw-sources/gcc-trunk/gcc/../libcpp/include
-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include
-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include
-I/temp/mingw-prereq/x86_64-w64-mingw32-static/include 
-I../../../../mingw-sources/gcc-trunk/gcc/../libdecnumber
-I../../../../mingw-sources/gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I../../../../mingw-sources/gcc-trunk/gcc/../libbacktrace   
../../../../mingw-sources/gcc-trunk/gcc/lto-compress.c -o lto-compress.o
../../../../mingw-sources/gcc-trunk/gcc/lto-compress.c:28:18: fatal error:
zlib.h: No such file or directory
compilation terminated.
make[2]: *** [lto-compress.o] Error 1
make[2]: Leaving directory
`/temp/x64-trunk-snapshot-posix-seh-rev3/build/gcc-trunk/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory
`/temp/x64-trunk-snapshot-posix-seh-rev3/build/gcc-trunk'
make: *** [all] Error 2

[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |bootstrap
            Version|lto                         |4.8.0

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-09 16:15:57 UTC ---
> --with-system-zlib 

You said zlib.h is included with the system but you don't update CXXFLAGS only
CFLAGS.

[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found

[alexpux at gmail dot com]

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

--- Comment #2 from Alexey Pavlov <alexpux at gmail dot com> 2013-01-09 16:31:18 UTC ---
Do I need add include paths to CXXFLAGS?
But I successfully build gcc-4.6.3 and 4.7.2 without add zlib include path to
CXXFLAGS only to CFLAGS.

[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-11-19
     Ever confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Yves Caniou from comment #3)
> I have the same problem when compiling gcc-4.8.2 with gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) on Xeon(R) CPU W3670  @ 3.20GHz
> Note that with the exact same process, I have been able to compile gcc-4.8.2
> with gcc 4.7.2 (debian).

Do you have a zlib.h installed?

For the original issue here, I think you need to use BOOT_CFLAGS and maybe
BOOT_CXXFLAGS.

[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found

[yves.caniou@ens-lyon.fr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 8355 bytes --]

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

--- Comment #5 from Yves Caniou <yves.caniou@ens-lyon.fr> ---
Le mardi 19 novembre 2013 02:36:30 pinskia at gcc dot gnu.org a écrit :
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55915
> 
> Andrew Pinski <pinskia at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED                 |WAITING
>    Last reconfirmed|                            |2013-11-19
>      Ever confirmed|0                           |1
> 
> --- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to Yves Caniou from comment #3)
> 
> > I have the same problem when compiling gcc-4.8.2 with gcc version 4.6.3
> > (Ubuntu/Linaro 4.6.3-1ubuntu5) on Xeon(R) CPU W3670  @ 3.20GHz
> > Note that with the exact same process, I have been able to compile
> > gcc-4.8.2 with gcc 4.7.2 (debian).
> 
> Do you have a zlib.h installed?
> For the original issue here, I think you need to use BOOT_CFLAGS and maybe
> BOOT_CXXFLAGS.

Indeed: /usr/include/zlib.h
And as I said, I could compile gcc-4.8.2 from 4.7.2 without any problem in the 
first place. Problems only appear when compiling gcc-4.8.2 with the new 
installation and all environment variables configured (at least as I thought: 
why would I use BOOT_FLAGS and how?)

.Y
>From gcc-bugs-return-435465-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 22 02:26:53 2013
Return-Path: <gcc-bugs-return-435465-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15800 invoked by alias); 22 Nov 2013 02:26:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15730 invoked by uid 48); 22 Nov 2013 02:26:48 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/19430] taking address of a var causes missing uninitialized warning
Date: Fri, 22 Nov 2013 02:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 3.4.2
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-19430-4-gh5go2YOcU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-19430-4@http.gcc.gnu.org/bugzilla/>
References: <bug-19430-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02242.txt.bz2
Content-length: 1808

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

--- Comment #27 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #26)
> (In reply to Manuel López-Ibáñez from comment #25)
> > I don't see any reason for -Wuninitialized to not enable
> > -Wmaybe-uninitialized.
> 
> I can see 3 kinds of use:
> 
> 1. Users who are interested in neither: they just don't use these options
> (if they want to use -Wall, they need the -Wno- version).

-Wall -Wno-uninitialized suppresses both.


> 2. Users interested in -Wuninitialized but not in -Wmaybe-uninitialized (to
> avoid potential many false positives). Because -Wuninitialized enables
> -Wmaybe-uninitialized, they need 2 options: -Wuninitialized
> -Wno-maybe-uninitialized. If -Wuninitialized did not enable
> -Wmaybe-uninitialized, only one option would be needed: -Wuninitialized.

This argument goes both ways: if you are interested in both warnings, you would
need both options.

> 3. Users interested in both. I think that -Wmaybe-uninitialized should
> enable -Wuninitialized because it makes no sense to have
> -Wmaybe-uninitialized but not -Wuninitialized. Indeed, if some variable is
> uninitialized, then it may be uninitialized. So, only one option should be
> needed in this case: -Wmaybe-uninitialized.

Aha! This is a really good point on which I can agree. However, it will
seriously break backwards compatibility for people that use either
-Wuninitialized or -Wno-uninitialized explicitly. I am not sure if the pain is
worth the beauty.

I don't think it is worth to discuss this in Bugzilla (specially not on this
PR). If you are convinced that this is the right thing to do, you could propose
a patch to gcc-patches and see how people receive it.
>From gcc-bugs-return-435466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 22 02:42:00 2013
Return-Path: <gcc-bugs-return-435466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24917 invoked by alias); 22 Nov 2013 02:41:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24899 invoked by uid 48); 22 Nov 2013 02:41:50 -0000
From: "mforney at mforney dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/59242] New: Ensure correct FLAGS are used at various stages of the build
Date: Fri, 22 Nov 2013 02:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mforney at mforney dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-59242-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02243.txt.bz2
Content-length: 1501

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY242

            Bug ID: 59242
           Summary: Ensure correct FLAGS are used at various stages of the
                    build
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mforney at mforney dot org

Created attachment 31268
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id1268&actioníit
Fixes issues 2 and 3

Hi,

I've encountered several areas in which incorrect flags are being used due to
minor issues in configures/Makefiles.

* In fixincludes/Makefile.in, $(CPPFLAGS) is used in the compile rule, but is
not set above.
* In gcc/configure.ac, when cross-compiling, configure calls itself with
--host=${build}, but does not pass through CXX/CXXFLAGS.
* Also in gcc/configure.ac, when cross-compiling, configure does not set
BUILD_CXXFLAGS appropriately, causing CXXFLAGS for the host to be used.
* In Makefile.tpl, CPPFLAGS is set to $(CPPFLAGS_FOR_TARGET), and in
Makefile.def, CPPFLAGS_FOR_TARGET is included in flags_to_pass. However, from
what I can tell, the commit adding CPPFLAGS_FOR_TARGET was reverted in r141859.

I have attached patches fixing all but the last point, as I am unsure of how to
handle that. It seems potentially useful functionality to have (as well as
CPPFLAGS_FOR_BUILD), however, I'm sure it was reverted for a good reason.