qt-4.1.3 configured with "-release -qt-gif -no-qt3support"
c++ -c -pipe -fPIC -Wall -W -DQT_NDEBUG -DQT_GUI_LIB
-DQT_CRE_LIB -I.
-o sipQtGuipart0.o
sipQtGuipart0.cpp
c++ -headerpad_max_install_names -bundle -F/System/Library/Frameworks
-framework Python -o QtGui.so sipQtGuipart0.o
-framework QtGui -framework QtCore
/usr/bin/ld: Undefined symbols:
QPrinter::setPrintRange(QPrinter::PrintRange)
QPrinter::printRange() const
collect2: ld returned 1 exit status
make[1]: [QtGui.so] Error 1
make: [all] Error 2
I've found this to be a problem with qt, as a simple test.cpp proved.
compiling qt-4.1.3 with qt3 support seemed to work.

22.05.06 10:50:45, Patrick Stinson wrote:
qt-4.1.3 configured with "-release -qt-gif -no-qt3support"

c++ -c -pipe -fPIC -Wall -W -DQT_NDEBUG -DQT_GUI_LIB
-DQT_CRE_LIB -I.

-o sipQtGuipart0.o
sipQtGuipart0.cpp
c++ -headerpad_max_install_names -bundle -F/System/Library/Frameworks
-framework Python -o QtGui.so sipQtGuipart0.o
-framework QtGui -framework QtCore
/usr/bin/ld: Undefined symbols:
QPrinter::setPrintRange(QPrinter::PrintRange)
QPrinter::printRange() const
collect2: ld returned 1 exit status
make[1]: [QtGui.so] Error 1
make: [all] Error 2

I've found this to be a problem with qt, as a simple test.cpp proved.
compiling qt-4.1.3 with qt3 support seemed to work.

I already sent a message about this to this list, Phil didn't react at
all.

I also filed an issue with TT, they said it might be fixed Qt4.2.

Andreas

yeah, this is TrollTech's problem. I find it hard to imagine that a
stitch like -no-qt3support is broken in this ehemmbugfix release.

5/22/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
22.05.06 10:50:45, Patrick Stinson wrote:
qt-4.1.3 configured with "-release -qt-gif -no-qt3support"

c++ -c -pipe -fPIC -Wall -W -DQT_NDEBUG -DQT_GUI_LIB
-DQT_CRE_LIB -I.

-o sipQtGuipart0.o
sipQtGuipart0.cpp
c++ -headerpad_max_install_names -bundle -F/System/Library/Frameworks
-framework Python -o QtGui.so sipQtGuipart0.o
-framework QtGui -framework QtCore
/usr/bin/ld: Undefined symbols:
QPrinter::setPrintRange(QPrinter::PrintRange)
QPrinter::printRange() const
collect2: ld returned 1 exit status
make[1]: [QtGui.so] Error 1
make: [all] Error 2

I've found this to be a problem with qt, as a simple test.cpp proved.
compiling qt-4.1.3 with qt3 support seemed to work.

I already sent a message about this to this list, Phil didn't react at
all.

I also filed an issue with TT, they said it might be fixed Qt4.2.

Andreas

yeah, this is TrollTech's problem. I find it hard to imagine that a
stitch like -no-qt3support is broken in this ehemmbugfix release.

5/22/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
22.05.06 10:50:45, Patrick Stinson wrote:
qt-4.1.3 configured with "-release -qt-gif -no-qt3support"

c++ -c -pipe -fPIC -Wall -W -DQT_NDEBUG -DQT_GUI_LIB
-DQT_CRE_LIB -I.

-o sipQtGuipart0.o
sipQtGuipart0.cpp
c++ -headerpad_max_install_names -bundle -F/System/Library/Frameworks
-framework Python -o QtGui.so sipQtGuipart0.o
-framework QtGui -framework QtCore
/usr/bin/ld: Undefined symbols:
QPrinter::setPrintRange(QPrinter::PrintRange)
QPrinter::printRange() const
collect2: ld returned 1 exit status
make[1]: [QtGui.so] Error 1
make: [all] Error 2

I've found this to be a problem with qt, as a simple test.cpp proved.
compiling qt-4.1.3 with qt3 support seemed to work.

I already sent a message about this to this list, Phil didn't react at
all.

I also filed an issue with TT, they said it might be fixed Qt4.2.

Andreas

22.05.06 12:16:03, Patrick Stinson wrote:
yeah, this is TrollTech's problem. I find it hard to imagine that a
stitch like -no-qt3support is broken in this ehemmbugfix release.

Well, this is just an "oversight", however it's one with a rather large
impact. There are other "oversights" found in Qt4.1, but not all of them
have such an impact.

The problem for TT here is that adding the necessary macro here would
break either forward or backward binary compatibility.

However, using the 0519 snapshot of PyQt4 I can happily compile and
install with a Qt4 built with -no-qt3support (i.e. no printRange symbol
in libQtGui). I can't see wether Phil added anything (I don't know sip
to well)

Andreas

5/22/06, Patrick Stinson <patrickkidd.lists (AT) gmail (DOT) comwrote:
Hmm. I don't find PyQt4 to even come into the picture here, as the
following code shows the same error whne compiled w/o qt3 support. I'm
just sticking with a full build for now.

int main()
{
QPrinter *p;
p->setPrintRange(QPrinter::AllPages);
}
--
5/22/06, Phil Thompson <phil (AT) riverbankcomputing (DOT) co.ukwrote:
Monday 22 May 2006 9:48 pm, Andreas Pakulat wrote:
22.05.06 12:16:03, Patrick Stinson wrote:
yeah, this is TrollTech's problem. I find it hard to imagine that a
stitch like -no-qt3support is broken in this ehemmbugfix release

Well, this is just an "oversight", however it's one with a rather large
impact. There are other "oversights" found in Qt4.1, but not all of them
have such an impact.

The problem for TT here is that adding the necessary macro here would
break either forward or backward binary compatibility.

Would it? It's not virtual.

However, using the 0519 snapshot of PyQt4 I can happily compile and
install with a Qt4 built with -no-qt3support (i.e. no printRange symbol
in libQtGui). I can't see wether Phil added anything (I don't know sip
to well)

I haven't done anything so I would expect it to be still broken.

Phil

PyKDE mailing list PyKDE (AT) mats (DOT) imk.fraunhofer.de

>
>
>

22.05.06 22:40:44, Phil Thompson wrote:
Monday 22 May 2006 9:48 pm, Andreas Pakulat wrote:
22.05.06 12:16:03, Patrick Stinson wrote:
yeah, this is TrollTech's problem. I find it hard to imagine that a
stitch like -no-qt3support is broken in this ehemmbugfix release.

Well, this is just an "oversight", however it's one with a rather large
impact. There are other "oversights" found in Qt4.1, but not all of them
have such an impact.

The problem for TT here is that adding the necessary macro here would
break either forward or backward binary compatibility.

Would it? It's not virtual.

Sorry, I confused the words of the support engineer. Here's his full
statement:

,
| It turns out that the reason for this is that in qprinter.cpp,
| QPrinter::setPrintRange() and QPrinter::printRange() are guarded by:
|
| #if defined(QT3_SUPPRT) && !(defined(QT_NPRINTDIALG))
|
| #endif // QT3_SUPPRT
|
| However, they are not similarly guarded by QT3_SUPPRT in qprinter.h.
|
| development team is aware of the issue and I believe this is getting
| changed going forward. The risk of doing so is that forward
| compatibility will be broken in the case where QT3_SUPPRT is not
| defined. But that is preferable to the current situation, where
| versions of Qt built with and without QT3_SUPPRT defined are not
| binary compatible over the documented API.
`

However, using the 0519 snapshot of PyQt4 I can happily compile and
install with a Qt4 built with -no-qt3support (i.e. no printRange symbol
in libQtGui). I can't see wether Phil added anything (I don't know sip
to well)

I haven't done anything so I would expect it to be still broken.

Interesting. The symbols printRange and setPrintRange are still missing
from libQtGui_debug.so.4.1.3 (I don't build non-debug non-qt3support
here) and I can happily build PyQt4.

However, I just noticed: It's failing on import with the missing
symbols. I wonder which compiler/ Patrick is using (I have Debian
unstable, gcc 4.0.3 and Python 2.4.3)

Andreas

22.05.06 14:36:54, Patrick Stinson wrote:
5/22/06, Patrick Stinson <patrickkidd.lists (AT) gmail (DOT) comwrote:
>Hmm. I don't find PyQt4 to even come into the picture here, as the
>following code shows the same error whne compiled w/o qt3 support.

Well, my gcc is happily linking PyQt4 against the Qt4 with no qt3
support, however it doesn't link your example and I also get the missing
symbol when I try to import QtGui

I have no idea why this happens, see my reply to Phil for information
about my "build system"

Andreas

5/22/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
22.05.06 22:40:44, Phil Thompson wrote:
Monday 22 May 2006 9:48 pm, Andreas Pakulat wrote:
22.05.06 12:16:03, Patrick Stinson wrote:
yeah, this is TrollTech's problem. I find it hard to imagine that a
stitch like -no-qt3support is broken in this ehemmbugfix release

Well, this is just an "oversight", however it's one with a rather large
impact. There are other "oversights" found in Qt4.1, but not all of them
have such an impact.

The problem for TT here is that adding the necessary macro here would
break either forward or backward binary compatibility.

Would it? It's not virtual.

Sorry, I confused the words of the support engineer. Here's his full
statement:

,
| It turns out that the reason for this is that in qprinter.cpp,
| QPrinter::setPrintRange() and QPrinter::printRange() are guarded by:
|
| #if defined(QT3_SUPPRT) && !(defined(QT_NPRINTDIALG))
|
| #endif // QT3_SUPPRT
|
| However, they are not similarly guarded by QT3_SUPPRT in qprinter.h.
|
| development team is aware of the issue and I believe this is getting
| changed going forward. The risk of doing so is that forward
| compatibility will be broken in the case where QT3_SUPPRT is not
| defined. But that is preferable to the current situation, where
| versions of Qt built with and without QT3_SUPPRT defined are not
| binary compatible over the documented API.
`
--
However, using the 0519 snapshot of PyQt4 I can happily compile and
install with a Qt4 built with -no-qt3support (i.e. no printRange symbol
in libQtGui). I can't see wether Phil added anything (I don't know sip
to well)

I haven't done anything so I would expect it to be still broken.

Interesting. The symbols printRange and setPrintRange are still missing
from libQtGui_debug.so.4.1.3 (I don't build non-debug non-qt3support
here) and I can happily build PyQt4.

However, I just noticed: It's failing on import with the missing
symbols. I wonder which compiler/ Patrick is using (I have Debian
unstable, gcc 4.0.3 and Python 2.4.3)

S X 10.4.6, stock gcc4.0, stock Python-2.3.5

Andreas

This falls into basic compiler/linker theory.

This happens because when you link objects into an executable, it
links all the functions used in your program (setPrintRange in my
example) to their implementations. If the trolltech build left out the
implementation of setPrintRage, the linker will not be able to find it
when I "request" it in my example.

When you import a python module like PyQt4.QtGui it does the same
thing for all of the functions referenced in the module's code. This
is called dynamic, or run-time linking. The pyqt4 code generated by
sip references every function in the qt library (that is wrapped,
anyway), so when you import it, the linker binds (or links!) the
function reference (generated by sip in the python module) to the
actual binary data representing the function block (in the qt
library).

The C++ qt code containing QPrinter::setPrintRange was never linked
into the library, therefore it is a problem with their build system,
and has nothing to do with pyqt, and subsequently, Phil.

5/22/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
22.05.06 14:36:54, Patrick Stinson wrote:
5/22/06, Patrick Stinson <patrickkidd.lists (AT) gmail (DOT) comwrote:
>Hmm. I don't find PyQt4 to even come into the picture here, as the
>following code shows the same error whne compiled w/o qt3 support.
>
Well, my gcc is happily linking PyQt4 against the Qt4 with no qt3
support, however it doesn't link your example and I also get the missing
symbol when I try to import QtGui

I have no idea why this happens, see my reply to Phil for information
about my "build system"

Andreas

22.05.06 16:33:04, Patrick Stinson wrote:
This happens because when you link objects into an executable, it
links all the functions used in your program (setPrintRange in my
example) to their implementations. If the trolltech build left out the
implementation of setPrintRage, the linker will not be able to find it
when I "request" it in my example.

When you import a python module like PyQt4.QtGui it does the same
thing for all of the functions referenced in the module's code. This
is called dynamic, or run-time linking. The pyqt4 code generated by
sip references every function in the qt library (that is wrapped,
anyway), so when you import it, the linker binds (or links!) the
function reference (generated by sip in the python module) to the
actual binary data representing the function block (in the qt
library).

Well, that is all pretty clear, however what I don't understand is: why
does compiling PyQt4 fail for you but not for me did I overlook
something in the errors you sent?

Andreas

Didn't you say that my example code didn't work for you? Any code that
uses that function should not link with the library in question.

5/22/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
22.05.06 16:33:04, Patrick Stinson wrote:
This happens because when you link objects into an executable, it
links all the functions used in your program (setPrintRange in my
example) to their implementations. If the trolltech build left out the
implementation of setPrintRage, the linker will not be able to find it
when I "request" it in my example.

When you import a python module like PyQt4.QtGui it does the same
thing for all of the functions referenced in the module's code. This
is called dynamic, or run-time linking. The pyqt4 code generated by
sip references every function in the qt library (that is wrapped,
anyway), so when you import it, the linker binds (or links!) the
function reference (generated by sip in the python module) to the
actual binary data representing the function block (in the qt
library).

Well, that is all pretty clear, however what I don't understand is: why
does compiling PyQt4 fail for you but not for me did I overlook
something in the errors you sent?

Andreas

22.05.06 20:52:28, Patrick Stinson wrote:
Didn't you say that my example code didn't work for you? Any code that
uses that function should not link with the library in question.

You're missing my point: Why does PyQt4 compilation fail for you, but
not for me. Judging from a quick look at your first message, I guess
it's du to different gcc on a different S. That's all I wanted to know.

Andreas

gcc -framework whatever reports undefined symbols at the compile-time
intermediate linking phase. gcc -lwhatever does not.

See my previous post about run-time and compile-time linking.

When you import a module, it links the PyQt4 module with your qt4
libs. According to your trolltech announcement it is no suprise that
any shared library using those two functions (like PyQt4) will compile
correctly and fail on linking (like __import__('PyQt4')).

5/23/06, Andreas Pakulat <apaku (AT) gmx (DOT) dewrote:
22.05.06 20:52:28, Patrick Stinson wrote:
Didn't you say that my example code didn't work for you? Any code that
uses that function should not link with the library in question.

You're missing my point: Why does PyQt4 compilation fail for you, but
not for me. Judging from a quick look at your first message, I guess
it's du to different gcc on a different S. That's all I wanted to know.

Andreas