Bug 230224 - qt4: needless(?) use of -I/usr/include, -L/usr/lib
qt4: needless(?) use of -I/usr/include, -L/usr/lib
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qt4 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-27 11:23 EST by Rex Dieter
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-05 11:58:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2007-02-27 11:23:24 EST
-- Additional comment from laurent.rineau__fedora_extras@normalesup.org 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 rdieter@math.unl.edu 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 laurent.rineau__fedora_extras@normalesup.org 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 libCGAL.so (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/libCGAL.so 
is found before my libCGAL.so in $HOME/CGAL/lib/. :-(


-- Additional comment from rdieter@math.unl.edu 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 11:25:34 EST
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       =|"
mkspecs/common/linux.conf
#endif
#if "%{qt_libdir}" == "%{_libdir}"
#sed -i -e "s|^QMAKE_LIBDIR_QT.*=.*|QMAKE_LIBDIR_QT       =|"
mkspecs/common/linux.conf
#endif
Comment 2 Laurent Rineau 2007-02-27 11:59:27 EST
(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 12:38:43 EST
They end up with -I/QtCore/ gcc flags mostly.  Haven't run into any LIBDIR probs
yet.
Comment 4 Laurent Rineau 2007-02-27 13:51:29 EST
IMO, PyQt4's installer is broken. As far as I can see, the automatic detection 
of PyQt4's configure.py is strange (it uses a tool named SIP).

Maybe you should use the flags of ./configure.py to set config options my 
hand.
Comment 5 Rex Dieter 2007-02-28 12:17:06 EST
* Wed Feb 28 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 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
breakage.
Comment 6 Kevin Kofler 2007-03-03 19:35:57 EST
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:
QMAKE_LIBDIR = $$KDEPREFIX/lib $$QMAKE_LIBDIR
(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 
too.
Comment 7 Kevin Kofler 2007-03-03 19:47:37 EST
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 11:58:48 EST
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.

Closing.

Note You need to log in before you can comment on or make changes to this bug.