Bug 223663

>I have tried to understand your choices of what is packaged in %{_libdir} and 
>what is in %{_datadir}, and I am not sure to understand.

The original rationale was not multilib, but FHS compliance.  Took hints from
other distros, mostly.

>1) Why %{_libdir}/qt4/examples/ (in qt4-doc) while this directory only 
> contains crossplatform source code?

Look closer. (:  It also contains binaries built from said source code,
browseable via qtdemo

2) Is a valid multilib issue.  2 approaches:
a.  Move this back to %{_libdir}/qt4/mkspecs
b.  See if qt4 can support using *both* %_libdir/qt4/mkspecs and
%_datadir/qt4/mkspecs, and put the multilib-conflicting bits in
%_libdir/qt4/mkspecs (I was only previously aware of the 'default' symlink, but
you may also be right about qconfig).

(If you agree, I would like to make this bug be a tracker for all multilib 
issues of qt4-devel, without creating separate bugs. I chance again the title. 
Please revert this change if you do not agree.)

%{_includedir}/QtCore/qconfig.h is another multilib issue.

This grep for "86" in %{_includedir}/Qt* seems to show that it is the only 
one: other i386 files are included according to proprocessor macros defined in 
<qconfig.h>.

Using this as a blocker is fine.

Here's the results of my quick-n-dirty multilib/conflicts test using my
el4.x86_64 box, the offenders/conflicts are:
/usr/include/Qt/qconfig.h 
/usr/include/QtCore/qconfig.h 
/usr/share/qt4/mkspecs/common/g++.conf 
/usr/share/qt4/mkspecs/default 
/usr/share/qt4/mkspecs/qconfig.pri 

qconfig.h is fixable, by doing something like:
rename Qt/qconfig.h Qt/qconfig-%{arch}.h
and create a new qconfig.h containing:
#include <Qt/qconfig-%{arch}.h>

For mkspecs conflicts, I'm still not sure.

(In reply to comment #3)
> /usr/include/Qt/qconfig.h 
> /usr/include/QtCore/qconfig.h 

Same file.

> /usr/share/qt4/mkspecs/common/g++.conf 

It would be nice that Fedora's %{optflags} do not end in that file. We do not 
want to impose them to users.

> qconfig.h is fixable, by doing something like:
> rename Qt/qconfig.h Qt/qconfig-%{arch}.h
> and create a new qconfig.h containing:
> #include <Qt/qconfig-%{arch}.h>

Agree.

> For mkspecs conflicts, I'm still not sure.

I have begun to look in the code of qmake. It should be possible to make it 
look in several directories. The env variable QMAKEPATH can contain a list of 
directories.

> It would be nice that Fedora's %{optflags} do not end in that file. We do not 
> want to impose them to users.

I don't think I'd agree with you here.  qt4 apps should, by default, be built 
using the same flags used to build qt4.  If folks don't like/want that, they're 
free to modify it as they see fit (perhaps we could mark those mkspecs files %
config).

> The env variable QMAKEPATH can contain a list of directories.

I was hoping to come up with a solution that "just works" without resorting to 
env variables (but will resort to that if no better solution presents itself).

(In reply to comment #5)
> > It would be nice that Fedora's %{optflags} do not end in that file. We do 
not 
> > want to impose them to users.
> 
> I don't think I'd agree with you here.  qt4 apps should, by default, be 
built 
> using the same flags used to build qt4.  If folks don't like/want that, 
they're 
> free to modify it as they see fit (perhaps we could mark those mkspecs 
files %
> config).

Actually, I think that there should be two platform fedora-32 and fedora-64 in 
$QTDIR/mkspecs/. See mkspecs/common/linux.conf, which is included by 
mkspecs/default/qmake.conf. That file defines several variables that are not 
accurate for Fedora:

QMAKE_INCDIR_X11      = /usr/X11R6/include
QMAKE_LIBDIR_X11      = /usr/X11R6/lib

QMAKE_INCDIR_OPENGL   = /usr/X11R6/include
QMAKE_LIBDIR_OPENGL   = /usr/X11R6/lib

What is more, we should have a kind of /etc/qt4/fedora-32.conf 
and /etc/qt4/fedora-64.conf in /etc, which defines the main flags.

> > The env variable QMAKEPATH can contain a list of directories.
> 
> I was hoping to come up with a solution that "just works" without resorting 
to 
> env variables (but will resort to that if no better solution presents 
itself).

I meant that, if qmake is enable to look in a list of directories, I should be 
possible to hard-code a default list of directories in its source code (with a 
patch).

Created attachment 148274 [details]
Patch for qt4-4.2.2-2.

(In reply to comment #6)
> Actually, I think that there should be two platform fedora-32 and fedora-64
in 
> $QTDIR/mkspecs/. See mkspecs/common/linux.conf, which is included by 
> mkspecs/default/qmake.conf. That file defines several variables that are not 

> accurate for Fedora:
> 
> QMAKE_INCDIR_X11	= /usr/X11R6/include
> QMAKE_LIBDIR_X11	= /usr/X11R6/lib
> 
> QMAKE_INCDIR_OPENGL	= /usr/X11R6/include
> QMAKE_LIBDIR_OPENGL	= /usr/X11R6/lib

I have a patch, that create a platform mkspecs/linux-g++-fedora/, which should
be multilib. I have also remove all annoying LIBPATH and INCLUDEPATH (the flag
"-L/usr/lib" was making me crazy).

The prefix "linux-g++", in the name, is important: src/corelib/io/io.pri tests
for a platform name "linux-*".

This is a first step towards fix for multilib issue.

Thanks, I'll incorporate most of this into the next release.  I don't think I
agree with the need to create a separate "linux-g++-fedora" platform though.

On second thought, your implementation (after looking closer at the patch) looks
cleaner than any alternative I can think of right now... (:

Thank you.

Actually, the implementation is wrong as is: %{optflags} is not the same on 
i386 and x86_64.

Maybe linux-g++-fedora/linux-g++-64/ should be excluded from i386 builds, and 
linux-g++-fedora/linux-g++-32/ be excluded from x86_64 builds. And 
common/g++.conf (or at least it variable QMAKE_CFLAGS_RELEASE) should be moved 
in linux-g++-{32,64}/ too, because QMAKE_CFLAGS_RELEASE is the variable that 
is "sedded" into %{optflags}.

The same sort of things as for linux-g++-fedora/qmake.conf can be used for 
mkspecs/qconfig.pri.

As for qconfig.h, that one is easy. I hope that we can deal with multilib 
issue very soon.

But, at least, please kill that linker flag -L/usr/lib/!!! :-) It comes from 
the variable QMAKE_LIBDIR_QT in common/linux.conf

You could publish intermediate tries for patches in that bug, so that I can 
work with you, if you want.

(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!

working on it, slowly.  Turns out the header thing wasn't quite as trivial as I
previously thought, will need to iterate over all supported archs, using
something like:

/* qconfig.h */

#if defined(__i386__)
#include qconfig-i386.h
#elif defined(__x86_64__)
#include qconfig-x86_64.h
...
#endif

What harm does -L/usr/lib do exactly?  (It seems, to me, like a lot of extra
work to remove, for little gain)

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/. :-(

ah gotcha, not really a multilib issue though. (: I'll address that separately.

ok, I think we've got something workable, though I've found that the qconfig.h
modification breaks at least one app: PyQt4 (it's configure loads/groks
qconfig.h directly to parse QT_* defines).  I don't think there's any way around
that though.

Here's the specfile multilib additions (in a nutshell):
...
Source5: qconfig.h
...
%build
...
sed -i -e "s|-O2|$RPM_OPT_FLAGS|g" mkspecs/%{platform}/qmake.conf

%install
...
## multilib: qconfig
mv %{buildroot}%{qt_headerdir}/Qt/qconfig.h
%{buildroot}%{qt_headerdir}/Qt/qconfig-%{_arch}.h
install -p -m644 -D %{SOURCE5} %{buildroot}%{qt_headerdir}/Qt/qconfig.h
mv %{buildroot}%{qt_headerdir}/QtCore/qconfig.h
%{buildroot}%{qt_headerdir}/QtCore/qconfig-%{_arch}.h
install -p -m644 -D %{SOURCE5} %{buildroot}%{qt_headerdir}/QtCore/qconfig.h
## mkspecs/default
rm -f %{buildroot}%{qt_datadir}/mkspecs/default
mkdir %{buildroot}%{qtdir}/mkspecs
ln -s %{qt_datadir}/mkspecs/%{platform} %{buildroot}%{qtdir}/mkspecs/default
# omit non-platform linux-g++*
pushd %{buildroot}%{qt_datadir}/mkspecs
for specdir in linux-g++* ; do
  if [ "$specdir" != "%{platform}"]; then rm -rf "$specdir"; fi
done
popd

Created attachment 148871 [details]
multilib patch, take2

Created attachment 148872 [details]
multilib qconfig.h

(In reply to comment #17)
> Created an attachment (id=148871) [edit]
> multilib patch, take2

How will you handle %{_optflags}?

> How will you handle %{_optflags}?

sed -i -e "s|-O2|$RPM_OPT_FLAGS|g" mkspecs/%{platform}/qmake.conf

(In reply to comment #20)
> > How will you handle %{_optflags}?
> 
> sed -i -e "s|-O2|$RPM_OPT_FLAGS|g" mkspecs/%{platform}/qmake.conf

Yes. I have eventually seen that you have made mkspecs being in %{_libdir}, 
which solves the multilib issue.

> you have made mkspecs being in %{_libdir}, 

Only %{qtdir}/mkspecs/default lives there (for now).  Everything else is (still)
in %{qt_datadir}.

OK, now let's see if this sucker actually builds... (:

The deed is done, in devel/fc7 only (for now), will queue FC-5/FC-6 builds soonish.

%changelog
* Tue Feb 27 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-3
- drop ./configure -no-reduce-exports (ie, support visibility)
- multilib issues (#223663)

Upon further testing, qconfig-multilib didn't work in all cases, REOPENING. 
Need to change references to
#include<qconfig-%_arch.h> -> #include<QtCore/qconfig-%_arch.h>.

In retrospect (mostly after finding how broken PyQt4 is), I'm considering reverting
-datadir %{qt_datadir}
or more precisely, change qt_datadir from _datadir/qt4 back to %_libdir/qt4

(CC'd Frank/qt4-qsa).

I'm on the fence wrt qt_datadir, in a nutshell, options are:
1.  Stick with %_datadir/qt4 , live with extra hackery to make multilib work,
deal-with/fix broken packages (like PyQt4)
2.  revert back to %_libdir/qt4, reduces/eliminates multilib hackery.

opinions?

I would personally have preferred the hard way:
  - force Qt-4 being FSH compliant, with patches
  - force Qt-4 being multilib, with patches
  - give feedback to Trolltech to merge patches with upstream,
  - fix broken packages.

But I can understand that it is a lot of work. I have offered in the past to 
co-maintain some stuff with you, Rex, but :
  1/ I am not sure to be sufficiently involved in Fedora to have a right view 
of the The Right Thing In Fedora,
  2/ I have to finish my PhD thesis until end of June. => I will be even less 
involved in Fedora in the following months.

If you prefere not to delegate, or if nobody can co-maintain Qt-4 with you, I 
can understand that you prefere to go back to %{_libdir}/qt4/. That is not 
that bad.

That was my 2 cents.

> If you prefere not to delegate, or if nobody can co-maintain Qt-4 with you

You've demonstrated ample competence and earned my trust, and since I have a
general rule never turn down help, I'll go submit the request to add you as
co-maintainer. (:

And, you've convinced me to "do the right thing" wrt FHS, multilib.

Created attachment 148923 [details]
multilib qconfig.h, take 2

#include<qconfig-%_arch.h> -> #include<QtCore/qconfig-%_arch.h>

just noticed a typo in there, will fix that... (:

(In reply to comment #26)
> You've demonstrated ample competence and earned my trust, and since I have a
> general rule never turn down help, I'll go submit the request to add you as
> co-maintainer. (:

Unfortunately, I will be of little help, in next 4 months.

(In reply to comment #24)
> In retrospect (mostly after finding how broken PyQt4 is), I'm considering 
reverting
> -datadir %{qt_datadir}
> or more precisely, change qt_datadir from _datadir/qt4 back to %_libdir/qt4

It is possible to make PyQt4's configure.py use predefined flags, given on 
command line or by env variables, with limited autodetection?


As for other packages that use Qt4, what build tool do they use? I personally 
maintain Ipe, which only uses qmake-qt4 and make. That's why I only need that 
the qmake-qt4 is usable. sip seems to be another (broken) tool. It should be 
fixed, or worked around if possible.

> Unfortunately, I will be of little help, in next 4 months.

Just let me know when you're free/available again, and if you're still
interested in comaint...

> It is possible to make PyQt4's configure.py use predefined flags

Yeah, it's broken, but fixable.  It basically re-implements qmake without
actually using qmake. ):

You seem to have fixed the qconfig.h problem, or are about to fix it.

As for qt_datadir, I have one idea: what Qt considers as sharable data should 
remain sharable data. We know that mkspecs/default is a problem, as well as 
patched qmake.conf-and-friends.

My "linux-g++-fedora" platform was not that bad, I think. One important 
feature of if was that we do not modify the mkspecs provided by Trolltech.

I have a new implementation (not tested by lack of time), that allows to 
compile i386 qt applications on a x86_64, without any pain (if all dep libs 
are multilib):

1/ In the spec file, add:
=====================QUOTE============================
cat > mkspecs-modifications.sed <<ENDOFSCRIPT
# Use $RPM_OPT_FLAGS instead of -O2
s|-O2|$RPM_OPT_FLAGS|g
# undefine QMAKE_STRIP, so we get useful -debuginfo pkgs
s|^QMAKE_STRIP.*=.*|QMAKE_STRIP             =|
# Remove all occurence to /usr/X11R6
s|/usr/X11R6/.*||g
# Make QMAKE_INCDIR_QT and QMAKE_LIBDIR_QT be empty to avoid anoying 
# flags -I/usr/include and -L/usr/lib*
s|QMAKE_INCDIR_QT.*=.*|QMAKE_INCDIR_QT       =|
s|QMAKE_LIBDIR_QT.*=.*|QMAKE_LIBDIR_QT       =|
ENDOFSCRIPT

mkdir mkspecs/fedora
for d in linux-g++ linux-g++-32 linux-g++-64; do 
  cp -a mkspecs/$d mkspecs/common mkspecs/fedora/
done
sed -i -f mkspecs-modifications.sed mkspecs/fedora/*/*.conf
===============END=OF=QUOTE============================

2/ Remove QMAKE_CFLAGS_RELEASE from mkspecs/fedora/common/g++.conf, and add 
QMAKE_CFLAGS_RELEASE=%{optflags} to mkspecs/fedora/linux-g++-32/qmake.conf 
(or -64 if %{_lib}==lib64).

3/ Pass "-platform fedora/linux-g++-32" (or -64) to configure.

4/ Create a wrapper %{_libdir}/qt4/bin/qmake that sets the env variable 
QMAKESPEC=%{_datadir}/qt4/mkspecs/fedora/linux-g++-32 (or -64) before calling 
qmake (if QMAKESPEC is not already in the user environment).

5/ Remove mkspecs/default completely.

6/ Explain that in a README.Fedora file. It should be transparent for all 
non-broken packages or users that do not try to work with qmake internals, but 
it is even better if it is documented.

7/ Try to fix broken packages. :-(

Hmm... 4/5 looks interesting.  Once QMAKESPEC is set 'default' shouldn't be
needed.  

Though maybe we can set QMAKESPEC via (something like) /etc/profile/qt4.sh. 
Stuff other than qmake can/does use QMAKESPEC (sip and friends PyQt, PyQt4,
PyKDE), though maybe we could just manually set QMAKESPEC here, since it's a
relatively small subset of pkgs.

I'll keep pondering...  I think we're getting close to an ideal solution.

Well, release early/often, so here's an incremental improvement.

* Wed Feb 28 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-5
- fixup qconfig-multilib.h (#223663)
- qt4.(sh|csh): define QMAKESPEC (#223663)

(In reply to comment #32)
> Hmm... 4/5 looks interesting.  Once QMAKESPEC is set 'default' shouldn't be
> needed.

Do you maintain a package that uses qmake? In order to test. If not, you could 
try to "bootstrap Qt": skip configure, and use a compiled qmake (coming from 
an installed qt4-devel package) to compile libs of Qt (and not the tools).

It may work (but bug #230224 seems a blocker).

> Do you maintain a package that uses qmake?

I tested a few various qt4 pkgs, including PyQt4 and texmaker.

> It may work (but bug #230224 seems a blocker).

why?  This and bug #230224 aren't related, afaict.

(In reply to comment #35)
> > Do you maintain a package that uses qmake?
> 
> I tested a few various qt4 pkgs, including PyQt4 and texmaker.

PyQt4 does magic stuff to work around qmake. What about texmaker?

> > It may work (but bug #230224 seems a blocker).
> 
> why?  This and bug #230224 aren't related, afaict.

If you try to compile/bootstrap Qt libs with /usr/bin/qmake-qt4 (from Fedora), 
it can work correctly if qmake inserts -L/usr/lib and -I/usr/include at the 
beginning of flags.

> As for other packages that use Qt4, what build tool do they use?

KDE 4 uses cmake, so at least that will have to work. :-)

qt4-4.2.2-5 builds fail on ppc:
/usr/include/QtCore/qconfig.h:15:3: error: #error arch unsupported, see http:

%changelog
* Mon Mar 05 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-7
- fixup qconfig-multilib.h for powerpc/powerpc64 (#223663)

Ugh, more fun:

* Tue Mar 06 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.2-8
- multilib: qconfig.pri, /etc/profile.d/* (#223663)

This is starting to get rediculous, maybe qt_datadir needs to revert
%_datadir/qt4 -> %qtdir(%_libdir/qt4)
as the number of hacks to make %_datadir/qt4 work are mounting.

(In reply to comment #39)
> This is starting to get rediculous, maybe qt_datadir needs to revert
> %_datadir/qt4 -> %qtdir(%_libdir/qt4)
> as the number of hacks to make %_datadir/qt4 work are mounting.

We should work with upstream (Trolltech), so that Qt-4.3.0 helps this task. 
The datadir of Qt-4.x should be architecture independent.

Do you see a reasonable patch that could be merged upstream?

> Do you see a reasonable patch that could be merged upstream?

atm, no, but I'll start a discussion on the qt4-interest ml soon.

OK, this should do the trick

%changelog
* Tue Mar 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.2.3-1
- qt-4.2.3
- multilib: move arch-specific/conflicting mkspecs bit to %%qtdir/mkspecs (#223663)

arch-specific/conflicting mkspecs bits include:
default
qconfig.pri
linux-g++* (play it safe here)

Rex, what is the status of this bug? I have not managed to read all the story 
with details.

Uh, you accidentally changed the component, can you or someone in fedorabugs 
please change it back?

(In reply to comment #44)
> Uh, you accidentally changed the component, can you or someone in fedorabugs 
> please change it back?

Sorry. I hope my error will not change other fields (such as the owner).

Should be fully resolved now, closing.