Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 230224

Summary: qt4: needless(?) use of -I/usr/include, -L/usr/lib
Product: [Fedora] Fedora Reporter: Rex Dieter <rdieter>
Component: qt4Assignee: Rex Dieter <rdieter>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: kevin, laurent.rineau__fedora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-05 16:58:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Rex Dieter 2007-02-27 16:23:24 UTC
-- Additional comment from on
2007-02-26 12:58 EST --
(In reply to comment #10)
> But, at least, please kill that linker flag -L/usr/lib/!!! :-) It comes from 
> the variable QMAKE_LIBDIR_QT in common/linux.conf

What is the progress, on that topic? That "-L/usr/lib" really get me crazy!

-- Additional comment from on 2007-02-26 13:43 EST --
What harm does -L/usr/lib do exactly?  (It seems, to me, like a lot of extra
work to remove, for little gain)

-- Additional comment from on
2007-02-26 14:03 EST --
I am creating plugins for ipe (a drawing editor, see `rpm -qi ipe`). ipe uses 
Qt4, and ipe plugins usually use qmake.

If i add CONFIG+=qt in a .pro file, I get "-L/usr/lib" in linker flags.

My plugins use (see `rpm -qi CGAL`).

In the development stage, I want them to use a patched version of libCGAL, 
that I have in $HOME/CGAL/lib/. Even if I add $CGAL/CGAL/lib to LIBPATH, in my 
pro files, -L$CGAL/CGAL/lib comes after -L/usr/lib/... and /usr/lib/ 
is found before my in $HOME/CGAL/lib/. :-(

-- Additional comment from on 2007-02-26 14:27 EST --
ah gotcha, not really a multilib issue though. (: I'll address that separately.

Comment 1 Rex Dieter 2007-02-27 16:25:34 UTC
On trying to address this, I hit a few snags, so I'll leave out fixing this, for
now.  Here is the specfile comment I'll be including in the next build :)

## FIXME(?)
# On the surface, looks like a good idea to strip -I/usr/include, -L/usr/lib, 
# but it turns out qmake-consuming apps expect/use INCDIR/LIBDIR directly 
# (e.g. PyQt4, texmaker), and don't cope with null values
#if "%{qt_headerdir}" == "%{_includedir}"
#sed -i -e "s|^QMAKE_INCDIR_QT.*=.*|QMAKE_INCDIR_QT       =|"
#if "%{qt_libdir}" == "%{_libdir}"
#sed -i -e "s|^QMAKE_LIBDIR_QT.*=.*|QMAKE_LIBDIR_QT       =|"

Comment 2 Laurent Rineau 2007-02-27 16:59:27 UTC
(In reply to comment #1)
> On the surface, looks like a good idea to strip -I/usr/include, -L/usr/lib, 
> but it turns out qmake-consuming apps expect/use INCDIR/LIBDIR directly 
> (e.g. PyQt4, texmaker), and don't cope with null values

Why do not they cope with null values for INCDIR and LIBDIR?

Comment 3 Rex Dieter 2007-02-27 17:38:43 UTC
They end up with -I/QtCore/ gcc flags mostly.  Haven't run into any LIBDIR probs

Comment 4 Laurent Rineau 2007-02-27 18:51:29 UTC
IMO, PyQt4's installer is broken. As far as I can see, the automatic detection 
of PyQt4's is strange (it uses a tool named SIP).

Maybe you should use the flags of ./ to set config options my 

Comment 5 Rex Dieter 2007-02-28 17:17:06 UTC
* Wed Feb 28 2007 Rex Dieter <rdieter[AT]> 4.2.2-5
- null'ify QMAKE_LIBDIR_QT, leave QMAKE_INCDIR_QT alone for now. (#230224)

We'll 1/2 fix the problem, for now, pending further investigation on INCDIR

Comment 6 Kevin Kofler 2007-03-04 00:35:57 UTC
The -L/usr/lib issue can also be worked around in the .pro file for the 
software you're building. E.g. if you want to search $$KDEPREFIX/lib 
before /usr/lib, write this:
(I do this in my project so the KDE 3.80.3 libs in /opt/kde4/lib are found, not 
the KDE 3.5.6 ones in /usr/lib.)

I don't have this problem with /usr/include because the KDE 3 headers are 
in /usr/include/kde, but I guess doing the same with QMAKE_INCDIR will work 

Comment 7 Kevin Kofler 2007-03-04 00:47:37 UTC
Note: make that $$KDEPREFIX/lib$$system(kde4-config --libsuffix) for multilib 
compliance. ;-) (I accidentally copied the line from the "win32" section. Using 
cross-MinGW with qmake is fun too, by the way, even more so if you add KDE 
3.80.3 packages to the mix. ;-) ) But that doesn't matter for your use case 
anyway. :-)

Comment 8 Rex Dieter 2007-03-05 16:58:48 UTC
Looks like we're ok INCDIR-wise.  Quoting cpp man page:
Directories named by -I are searched before the standard system include
directories.  If the directory dir is a standard system include directory, the
option is ignored to ensure that the default search order for system directories
and the special treatment of system headers are not defeated .
Since /usr/include is one of the "standard system includes", -I/usr/include is
(should be!) ignored.