185621 - qt port should define QT_NO_STL

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

There have been several reports of compile problems when QT_NO_STL is not defined.
(see e.g. news://news.mozilla.org/netscape.public.mozilla.qt thread "Compile Error")

therefore, I'm attaching a patch to always define it (when qt is enabled).

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 2

[timeless]

*** Bug 185619 has been marked as a duplicate of this bug. ***

Comment 3

[timeless]

*** Bug 185620 has been marked as a duplicate of this bug. ***

Comment 4

[Roland Mainz]

Maybe we should make this define gcc-only since Sun Workshop works fine with
STL  in Qt enabled...

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

my gcc does too, but disabling it does not cause any harm, esp. given that
mozilla does not use stl either.

Comment 6

[hacker formerly known as [e-mail]]

Comment on attachment 109407 [details] [diff] [review]
patch

r=cls

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1139; previous revision: 1.1138
done

Comment 8

[Paul Floyd]

Just encountered this problem as well. As I understand it, the root of the
problem is that the "#include <string>" in qstring.h matches the name of a directory

[/export/home/dl/Qt-gcc/include/qstring.h:46: directory
`../../../dist/include/string' specified in #include]

IMO the correct fix would be to make sure that the header file is included not
the directory. One way might be to change the order of the include paths.
Another would be to change the name of the string directory so that it no longer
matches that of the name of one of the standard library headers. (Put another
way - would anyone put up with a directory called "iostream.h" ???)

Again as I understand it, setting QT_NO_STL will force all Qt users to
(re)compile a non-STL version of the Qt libraries.

See
http://lists.trolltech.com/qt-interest/2003-02/thread00069-0.html

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

>IMO the correct fix would be to make sure that the header file is included not
>the directory.

and how would you do that, without modifying system qt headers?

note that defining QT_NO_STL works just fine for me as well as others, I have
not heard a complaint of something not working.

Comment 10

[timeless]

vrfy fixed: 1.1139	cbiesinger%web.de	Dec 16 2002

note that the thread on the list is misleading.

What it means is that a STL based Qt app can't link against Qt w/o STL. It
doesn't say or mean to say that a Non STL based Qt app (mozilla) can't link
against Qt w/ STL.

the issue w/ <string> should be treated as a compiler bug. Even if it is mozilla
related, it does not in any way relate to this bug report.