[Bug build/18272] New: Build terminates with cannot remove /usr/include/limits.h

[Bug build/18272] New: Build terminates with cannot remove /usr/include/limits.h

[david_denny at verizon dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

            Bug ID: 18272
           Summary: Build terminates with cannot remove
                    /usr/include/limits.h
           Product: glibc
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: david_denny at verizon dot net
                CC: carlos at redhat dot com

Created attachment 8250
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8250&action=edit
Output during "make --debug=a -j1 2>&1 | tee log.file"

Beginning from clean source and following direction from "Linux From Scratch"
build terminates with:

/usr/bin/install -c -m 644 ../include/limits.h /usr/include/limits.h
/usr/bin/install: cannot remove '/usr/include/limits.h': Permission denied

The problem is highly reproducible.
1.) No specific distribution, but generally following / compatible with Linux
>From Scratch.
2.) Source is clean. 
3.) Platform is Dell PE 2900 with 8 3GHz Xeon procesors and lots of RAM
4.) GCC 2.9.1
5.) Make 4.1
6.) Kernel 3.19.0
7.) binutils-2.25
8.) gmp-6.0.0.a, mpfr-3.1.2, mpc-1.0.3
9.) All else pretty much up to date and known dependencies rebuilt and pass
their own tests.

These are the things I've tried:
1.) Running as non-root user.
2.) use -J1 on make
3.) Unset all relevant environment variables.
4.) Try to "touch" /usr/include/limits.h
5.) Turn on "make --debug=a" to generate tons of make file debugging - why does
it want to replace /usr/include/limits.h during non-root build?

The problem has persisted for me through several versions of GLIBC, at least
2.18 and 2.19 to the point where I developed a patch (hack) to continue.

I'm sure it is something, I acknowledge that, but how can I figure it out? 
Looks like some other people have had the same problem but "fix" it by fooling
around with the distro configurations till the problem goes away.

FWIW, glibc-2.21 builds perfectly on other machines of similar configuration
(i686 for example.)

I can upload anything you'd like, and I have uploaded a rather mammoth log
file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[david_denny at verizon dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

--- Comment #1 from David A. Denny <david_denny at verizon dot net> ---
Oops!

"I'm sure it is something"  in my configuration ", I acknowledge that,"

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[david_denny at verizon dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

--- Comment #2 from David A. Denny <david_denny at verizon dot net> ---
This is the "fix" (more likely a terrible hack) that I have put into the (top
level) Makerules to get past it trying to replace /usr/include/limits.h during
build.  (see commented out "do-install" line.)  At least maybe it's a clue.  I
wonder why its getting here?


headers := $(strip $(headers))
ifdef headers
# This implicit rule installs headers from the source directory.
# It may be ignored in preference to rules from sysd-rules to find
# headers in the sysdeps tree.
$(inst_includedir)/%.h: $(objpfx)%.h $(+force)
        $(do-install)
$(inst_includedir)/%.h: $(common-objpfx)%.h $(+force)
        $(do-install)
$(inst_includedir)/%.h: %.h $(+force)
        $(do-install)
$(inst_includedir)/%.h: $(..)include/%.h $(+force)
#       $(do-install)
headers-nonh := $(filter-out %.h,$(headers))
ifdef headers-nonh
$(addprefix $(inst_includedir)/,$(headers-nonh)): $(inst_includedir)/%: \
                                                 % $(+force)
        $(do-install)
endif   # headers-nonh
endif   # headers

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[david_denny at verizon dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

--- Comment #3 from David A. Denny <david_denny at verizon dot net> ---
Here is the configuration I'm using.   FWIW, I always start from clean (so the
make clean / distclean) are probably unnecessary, but then again the build
directory is empty too.

#!/bin/sh -x

make clean;
make distclean;

unset LD_LIBRARY_PATH
unset LIBRARY_PATH
unset PERL5LIB
unset PYTHONPATH
unset PKG_CONFIG_PATH

../glibc-2.21/configure    \
    --prefix=/usr          \
    --disable-profile      \
    --enable-kernel=2.6.32 \
    --enable-obsolete-rpc  \
  2>&1 | tee configure.log
exit;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
How do you invoke make?  “make install” (without DESTDIR at least) will need
root privileges.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-28046-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Apr 20 07:53:05 2015
Return-Path: <glibc-bugs-return-28046-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 27453 invoked by alias); 20 Apr 2015 07:53:05 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 27405 invoked by uid 48); 20 Apr 2015 07:53:01 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug stdio/18246] scanf "%2d" can incorrectly parse "0x" same for "%2f" with "1e"
Date: Mon, 20 Apr 2015 07:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: stdio
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc flagtypes.name
Message-ID: <bug-18246-131-RnWfFVqqgV@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-18246-131@http.sourceware.org/bugzilla/>
References: <bug-18246-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00104.txt.bz2
Content-length: 616

https://sourceware.org/bugzilla/show_bug.cgi?id\x18246

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
Is "0x" really the prefix of a valid input for the %d conversion specifier?  I
don't thin kso.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Does some .d file in your build tree mention /usr/include/limits.h?  If 
so, then investigate why.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[david_denny at verizon dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

--- Comment #6 from David A. Denny <david_denny at verizon dot net> ---
Thanks so much for the pointer!  

Yes - MANY do, this is one example...

I'll hunt through to try to figure out where / how it is getting in.

./login/ptsname_r_chk.os.d
 ../sysdeps/pthread/allocalim.h ../include/limits.h /usr/include/limits.h \

Thanks,

David

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 24 Apr 2015, david_denny at verizon dot net wrote:

> ./login/ptsname_r_chk.os.d
>  ../sysdeps/pthread/allocalim.h ../include/limits.h /usr/include/limits.h \

The include_next from include/limits.h should find the limits.h file from 
the compiler's include-fixed directory, not that from /usr/include.  So 
investigate why #include_next is finding the wrong file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[david_denny at verizon dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

--- Comment #8 from David A. Denny <david_denny at verizon dot net> ---
Hi Joseph,

Sorry to go lights out - many things going on, for months.

Your advice was spot on, and I have finally found out my mistake.

I had created a symlink from /usr/include to /usr/local/include because I just
want a flatter system.  For me, somethings things will "accidentally" wind up
in /usr/local instead of /usr and then there are version conflicts.  It seemed
like a good thing at the time but now turns out to be a terrible mistake.  Once
I removed the symlink, all worked perfectly.

I can honestly say that I've battled with this issue, only apparent in the
build of glibc, for years!  Funny how such a simple thing can cause such a
convoluted outcome.

Many thanks for your help!

Best regards,

David

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/18272] Build terminates with cannot remove /usr/include/limits.h

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18272

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #9 from Florian Weimer <fweimer at redhat dot com> ---
Thanks, David, for your explanation.  Closing as INVALID.

-- 
You are receiving this mail because:
You are on the CC list for the bug.