[MacPorts] #20199: qt4-mac fails to build

[MacPorts]

#20199: qt4-mac fails to build
----------------------------------+-----------------------------------------
 Reporter:  jwhowse4@…            |       Owner:  erickt@…           
     Type:  defect                |      Status:  new                
 Priority:  Normal                |   Milestone:                     
Component:  ports                 |     Version:  1.7.1              
 Keywords:                        |        Port:  qt4-mac            
----------------------------------+-----------------------------------------

Comment(by boeyms@…):

 I get the same problem as the original poster; the problem in that case
 arises because:

  * the build is occurring on a case-preserving but not case-sensitive
 (e.g. HFS+)
  * libevent is installed;
  * {{{-I${prefix}/include}}} appears before the other {{{-I}}} flags in
 the command that causes the failure;
  * gcc therefore ends up including ${prefix}/include/Event.h instead of
 event.h inside the build directories (hence the importance of the
 filesystem not being case-sensitive).

 Deactivating or uninstalling libevent during the build works around this
 problem.

 Replying to [comment:8 ryandesign@…]:
 > MacPorts puts -I${prefix}/include in CPPFLAGS and -L${prefix}/lib in
 LDFLAGS. You can clear configure.cppflags and/or configure.ldflags if you
 don't want these.


 As Qt 4 builds against third-party libraries, this will result in the port
 either linking against system libraries (zlib, openssl), building and
 linking against internal ones (possibly libtiff, libpng, libmng, libjpeg),
 or building without support for a feature (dbus).  (Actually, we may also
 get error reports from people who have stuff in /usr/local, since the
 "linking against system libraries" actually means GCC using its default
 search paths for system libraries, and that has /usr/local/include before
 /usr/include.)  This probably won't be a problem for most Qt 4 programs,
 but violates MacPorts policy, and will make the installation larger.

 The two solutions that I can think of are:

  1. trying to get the upstream developers to include configure-time
 CPPFLAGS and CFLAGS contents after the stuff that they generate themselves
 (I don't know whether or not there are any reasons they would not do
 this); and
  1. switching the MacPorts-supplied "-I${prefix}/include" argument to
 "-isystem ${prefix}/include".

 According to the C preprocessor guide available via XCode's documentation,
 the latter of these has the effect of:

  1. ensuring ${prefix}/include is searched after all directories specified
 by -I, but before the default system directories; and
  1. switching off a few (unspecified) warnings that headers for the OS and
 its runtime libraries often generate because they often cannot be written
 in strictly conforming C.

 I don't imagine either of these would be a problem for anything other than
 the dependence on a flag (-isystem) that may be GCC-specific, though
 someone more knowledgeable than may be able to say otherwise.

-- 
Ticket URL: <http://trac.macports.org/ticket/20199#comment:9>
MacPorts <http://www.macports.org/>
Ports system for Mac OS