Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Nov 2014 00:49:30 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 195490] New: devel/mingw32-gcc build affected by similar-named files in /usr/local/include
Message-ID:  <bug-195490-13@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195490

            Bug ID: 195490
           Summary: devel/mingw32-gcc build affected by similar-named
                    files in /usr/local/include
           Product: Ports Tree
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs@FreeBSD.org
          Reporter: bobf@mrp3.com
                CC: cyberbotx@cyberbotx.com
                CC: cyberbotx@cyberbotx.com
             Flags: maintainer-feedback?(cyberbotx@cyberbotx.com)

using a slightly older version of devel/mingw32-gcc

  mingw32-gcc-4.7.2_1,1

I attempted to build it using the unmodified port, but had a problem with a
specific include file "unwind.h".  it appears that if another port/package
(such as devel/libunwind) is installed, and places a duplicate-name header file
into /usr/local/include, then the mingw32-gcc build may not work properly
(#includes the wrong file, basically).

The solution appears to be to comment out (or remove) the following line in
Makefile :

CFLAGS+=       -I${LOCALBASE}/include

Without this addition to CFLAGS, the configure script STILL includes
/usr/local/include in its search path; however, it appears LATER in the command
line and thereby this prevents problems with aliasing of include files from
/usr/local/include.

On examination of the Makefile in 'freshports', it appears that the latest will
have the same problem.  In effect, ANY installed port that produces an
incompatible include file that aliases one needed by the gcc build will result
in the SAME kinds of problems, maybe even causing crashes, etc.

Other gcc cross-compilers should be checked to see if they do the same thing.
Header file aliasing could easily mess THEM up as well.

--- Comment #1 from Bugzilla Automation <bugzilla@FreeBSD.org> ---
Maintainer CC'd

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-195490-13>