[Development] Fixing the DLL/shared/static mess

[Thiago Macieira]

I ran into Ossi and Marius S.O. talking about the mess we have with the build
and use of Qt as shared/DLL or static. It's something I had begun fixing, but I
haven't finished yet.

If you're dealing with a different buildsystem than qmake, or you're packaging
Qt, please my email that is a reply to this:

Problem 1:
we have qmake CONFIG += static shared dll staticlib
but each one has different behaviour due to the way that aliases work

Therefore:
qmake CONFIG += staticlib and dll are *deprecated* as of now

Please use only shared and static only. Those configs determine whether your
library output will be a static library or a shared library or DLL. They affect
only compiler and linker build options, but not any DEFINES you may need when
building your Windows DLL. That's entirely up to you.


Problem 2:
we have QT_MAKEDLL, QT_DLL, QT_STATIC, QT_SHARED
we only need one: QT_STATIC (exclusive of QT_SHARED)

Therefore, QT_MAKEDLL will be removed altogether.

Qt builds with -shared (the default) will have in qconfig.h:

#ifndef QT_STATIC
#define QT_SHARED
#define QT_DLL
#endif

Qt builds with -static will have in in qconfig.h:

#ifndef QT_SHARED
#define QT_STATIC
#endif

All the Q_*_EXPORT macros will be adapted to the form:

#ifndef QT_STATIC
# ifdef QT_BUILD_XXX_LIB
# define Q_XXX_EXPORT Q_DECL_EXPORT
# else
# define Q_XXX_EXPORT Q_DECL_IMPORT
# endif
#else // QT_STATIC
# define Q_XXX_EXPORT
#endif

Implications:

1) QT_STATIC determines the type of Qt that some code is *using*. Since all
modules except for QtCore use another Qt module, this decision is valid for Qt
as well. Therefore, *ALL* Qt libraries must be either static or shared. Mixed
builds will not be supported

This does not apply to QtPlatformSupport and winmain. Those are not
considered Qt libraries: winmain is added implicitly to your Windows builds,
whereas QtPlatformSupport is entirely private API. They will continue being
distributed as .a and .lib files (for now, at least).

2) QT_STATIC should not be used for making decisions outside of Qt (i.e.,
modules built using qt_module_config.prf). You're entirely on your own if you
do that.

3) If you're not doing that, we expect no impact to regular applications or
libraries using Qt, no change necessary to your code or .pro files or whatever
buildsystem (one exception, see next email)

4) Packagers who package only one type of Qt build (shared or static, but not
both), should not see any changes either. One Qt build means a set of library
files and the headers (e.g.: libQtCore.so and qconfig.h).


Over the next couple of weeks, we'll go over the Qt modules in qt5.git and
adapt them to the macros. we'll also take the opportunity to move the
Q_XXX_EXPORT macros to the library in question. qglobal.h will only define the
macros for a subset of qtbase which can never be split apart (QtCore,
QtNetwork, QtGui).

I really expect this to cause no breakages, but we'll only know more once we
start doing and see what problems they might introduce.

[Thiago Macieira]

Post by Thiago Macieira
I ran into Ossi and Marius S.O. talking about the mess we have with the
build and use of Qt as shared/DLL or static. It's something I had begun
fixing, but I haven't finished yet.
If you're dealing with a different buildsystem than qmake, or you're

The word "read" in "please read my email" was missing.

Post by Thiago Macieira
4) Packagers who package only one type of Qt build (shared or static, but
not both), should not see any changes either. One Qt build means a set of
library files and the headers (e.g.: libQtCore.so and qconfig.h).

THIS IS A PROPOSAL

A static-and-shared build of Qt is currently not supported. There are no plans
to accomplish this with the current buildsystem in one build.

However, it might be possible to do it in two builds. If you want to try this,
the recommendation is:

1) configure Qt for shared
2) build and install all libs and headers, including qconfig.h, qconfig.pri
3) configure Qt for static
4) build but install *only* the library files; do NOT overwrite qconfig.h
5) report back to the mailing list because we need the feedback

ASSUMPTION: you *can* have both sets of libraries installed in the same place
and your linker will link to the shared Qt if no extra command-line options
are passed.

On Windows, since linking to a DLL actually links to a static import library,
the above is not possible.

Buildsystems should be changed to support compile-time selection of which one
to link to.

For qmake, the proposed solution is:
CONFIG += prefer_shared_qt
CONFIG += prefer_static_qt

prefer_shared_qt is a no-op, since it's the default

prefer_static_qt defines QT_STATIC and must also use a static linking form:

-static -lQtQml -lQtGui -lQtCore -shared $dependent_libs

The dependent libs need to be read from each lib's .prl file LIBS_PRIVATE
variable (currently not set).

[Stephen Kelly]

Post by Thiago Macieira

Post by Thiago Macieira
4) Packagers who package only one type of Qt build (shared or static, but
not both), should not see any changes either. One Qt build means a set of
library files and the headers (e.g.: libQtCore.so and qconfig.h).

THIS IS A PROPOSAL
A static-and-shared build of Qt is currently not supported. There are no
plans to accomplish this with the current buildsystem in one build.

Hmm, when I worked on the CMake buildsystem files, I thought static-and-shared
was the default on Mac (or maybe it was Windows), or I had to support it for
that reason. Has that changed or am I imagining/misremembering it?

I also (mis)remember that this shared_and_static option doesn't work on linux
at all? Is this a mac-only feature?

Post by Thiago Macieira
Buildsystems should be changed to support compile-time selection of which
one to link to.
CONFIG += prefer_shared_qt
CONFIG += prefer_static_qt
prefer_shared_qt is a no-op, since it's the default
-static -lQtQml -lQtGui -lQtCore -shared $dependent_libs

The CMake equivalent would probably be a Qt5$${MODULE}_USE_STATIC_LIBS option.
I'll look into it.

Thanks,

[Thiago Macieira]

Post by Stephen Kelly

Post by Thiago Macieira

Post by Thiago Macieira
4) Packagers who package only one type of Qt build (shared or static, but
not both), should not see any changes either. One Qt build means a set of
library files and the headers (e.g.: libQtCore.so and qconfig.h).

THIS IS A PROPOSAL
A static-and-shared build of Qt is currently not supported. There are no
plans to accomplish this with the current buildsystem in one build.

Hmm, when I worked on the CMake buildsystem files, I thought
static-and-shared was the default on Mac (or maybe it was Windows), or I
had to support it for that reason. Has that changed or am I
imagining/misremembering it?

You may be confusing static-and-shared with debug-and-release. That's the
default on Mac and Windows.

Static and shared in one build has never been supported.

Post by Stephen Kelly
I also (mis)remember that this shared_and_static option doesn't work on
linux at all? Is this a mac-only feature?

It doesn't work anywhere. The option doesn't exist yet.

Post by Stephen Kelly

Post by Thiago Macieira
Buildsystems should be changed to support compile-time selection of which
one to link to.
CONFIG += prefer_shared_qt
CONFIG += prefer_static_qt
prefer_shared_qt is a no-op, since it's the default
-static -lQtQml -lQtGui -lQtCore -shared $dependent_libs

The CMake equivalent would probably be a Qt5$${MODULE}_USE_STATIC_LIBS
option. I'll look into it.

It's far more likely that CMake and other buildsystems can accomplish this,
even if qmake can't. In order to do that, we need to have a sane qconfig.h and
export macros. That's what this proposal is about.

[Stephen Kelly]

Post by Thiago Macieira

Post by Stephen Kelly

Post by Thiago Macieira

Post by Thiago Macieira
4) Packagers who package only one type of Qt build (shared or
static,
but
not both), should not see any changes either. One Qt build means a set of
library files and the headers (e.g.: libQtCore.so and
qconfig.h).

THIS IS A PROPOSAL
A static-and-shared build of Qt is currently not supported. There
are no plans to accomplish this with the current buildsystem in one
build.>

Hmm, when I worked on the CMake buildsystem files, I thought
static-and-shared was the default on Mac (or maybe it was Windows), or I
had to support it for that reason. Has that changed or am I
imagining/misremembering it?

You may be confusing static-and-shared with debug-and-release. That's the
default on Mac and Windows.

Yes, you are correct.

Post by Thiago Macieira
Static and shared in one build has never been supported.

But you want to make it supported in one package? Has that been possible
before?

Post by Thiago Macieira
It's far more likely that CMake and other buildsystems can accomplish this,
even if qmake can't. In order to do that, we need to have a sane qconfig.h
and export macros. That's what this proposal is about.

Right. I might have to have another closer look at the proposal tomorrow then.
A solution that works for qmake can probably be adapted anyway, as you note.

Thanks,

[Thiago Macieira]

Post by Stephen Kelly

Post by Thiago Macieira
Static and shared in one build has never been supported.

But you want to make it supported in one package? Has that been possible
before?

Not right now. It's extremely unlikely we'll modify qmake to support it. But
this might be possible in a new buildsystem.

Either way, the point is that you might have two builds making one
installation.

Post by Stephen Kelly

Post by Thiago Macieira
It's far more likely that CMake and other buildsystems can accomplish this,
even if qmake can't. In order to do that, we need to have a sane qconfig.h
and export macros. That's what this proposal is about.

Right. I might have to have another closer look at the proposal tomorrow
then. A solution that works for qmake can probably be adapted anyway, as
you note.

[Loaden]

This changed broken qbs build on Windows (MSVC2010SP1):
96166fa56abb52157387c4911efbd4e5e6beee93
After change CONFIG += staticlib to CONFIG += static (src\lib\lib.pro) still
can't solved the build issue.
Any comments?

commandexecutor.cpp
transformer.cpp
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(65)
: error C2470: 'Exception' : looks like a function definition, but there is
no parameter list; skipping apparent body
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(72)
: error C2470: 'UnhandledException' : looks like a function definition, but
there is no parameter list; skipping apparent body
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(85)
: error C2061: syntax error : identifier 'Exception'
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(89)
: error C2143: syntax error : missing ';' before '*'
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(89)
: error C4430: missing type specifier - int assumed. Note: C++ does not
support default-int
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(89)
: error C4430: missing type specifier - int assumed. Note: C++ does not
support default-int
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(89)
: warning C4183: 'exception': missing return type; assumed to be a member
function returning 'int'
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentexception.h(94)
: error C2470: 'ExceptionStore' : looks like a function definition, but
there is no parameter list; skipping apparent body
d:\qpsoft\projects\buildqt5-x86\qtbase\include\qtconcurrent\../../../../Qt5/qtbase/src/concurrent/qtconcurrentresultstore.h(82)
: error C2470: 'ResultIteratorBase' : looks like a function definition, but
there is no parameter list; skipping apparent body

Post by Stephen Kelly

Post by Thiago Macieira
Static and shared in one build has never been supported.

But you want to make it supported in one package? Has that been possible
before?

Not right now. It's extremely unlikely we'll modify qmake to support it. But
this might be possible in a new buildsystem.
Either way, the point is that you might have two builds making one
installation.

Post by Stephen Kelly

Post by Thiago Macieira
It's far more likely that CMake and other buildsystems can accomplish this,
even if qmake can't. In order to do that, we need to have a sane

qconfig.h

Post by Stephen Kelly

Post by Thiago Macieira
and export macros. That's what this proposal is about.

Right. I might have to have another closer look at the proposal tomorrow
then. A solution that works for qmake can probably be adapted anyway, as
you note.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

[Joerg Bornemann]

Post by Loaden
96166fa56abb52157387c4911efbd4e5e6beee93
After change CONFIG += staticlib to CONFIG += static (src\lib\lib.pro
<http://lib.pro>) still can't solved the build issue.
Any comments?

This has nothing to do with Qt.
Like Qt Creator, qbs copied some files from QtConcurrent.
The culprit is src/lib/qtconcurrent/qtconcurrent_global.h in qbs.
Will fix it.


BR,

Jörg
--
Joerg Bornemann
Senior Engineer
Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori

[Uwe Rathmann]

Post by Thiago Macieira
Therefore, *ALL* Qt libraries must be either static or shared. Mixed
builds will not be supported

Maybe this is a silly question, but what makes a library to be a Qt
library ?
Or asking the other way round: what is the difference between a module
like QtSvg and 3rd party libraries like Qwt or Qxt - beside where they
are hosted ?

As far as I understand one of the ideas behind the modularization is to
develop modules more independent, what makes these modules sooner or
later very similar to 3rd party libraries.

Uwe

[Thiago Macieira]

Post by Uwe Rathmann

Post by Thiago Macieira
Therefore, *ALL* Qt libraries must be either static or shared. Mixed
builds will not be supported

Maybe this is a silly question, but what makes a library to be a Qt
library ?
Or asking the other way round: what is the difference between a module
like QtSvg and 3rd party libraries like Qwt or Qxt - beside where they
are hosted ?

I'd say:
1) where they are installed
2) whether they use qt_module_config.prf or equivalent or a future replacement
3) whether they follow Qt conding conventions -- including headers and macros
to be used, like QT_STATIC
4) library and API naming
5) development workflow and other Qt Project rules

Post by Uwe Rathmann
As far as I understand one of the ideas behind the modularization is to
develop modules more independent, what makes these modules sooner or
later very similar to 3rd party libraries.

All Qt libraries are first-party: they come from the Qt Project.

[Uwe Rathmann]

Hi Thiago,

my interest is of course to benefit as much as possible from the ideas
and solutions of the Qt development
and I believe the best way should be to organize my code and build
environment like Qt libraries do.

Post by Thiago Macieira
1) where they are installed

I wouldn't install Qwt into the same place where Qt is, because it works
with different binary compatible installations of Qt.
But of course it would be possible to do so for the same reasons you do
it with a module like Qt SVG.

Post by Thiago Macieira
2) whether they use qt_module_config.prf or equivalent or a future replacement

I'm not sure if this would be possible for code outside the Qt source tree ?

Post by Thiago Macieira
3) whether they follow Qt conding conventions -- including headers and macros
to be used, like QT_STATIC

I have the same code base for Qt4 and Qt5 ( like the creator ) what
might require some extra ifdefs, but in general it should be possible -
as long as I'm aware of existing conventions.

Post by Thiago Macieira
4) library and API naming

similar to 4.

Post by Thiago Macieira
5) development workflow and other Qt Project rules

I don't believe, that I could develop in the same release cycles as the
Qt library itself ( f.e I have no idea yet what it means to adopt Qwt to
QML )

The only reason why I'm doing the Qwt project for such a long time ( >
10 years ) is because I only do it when I like to.
If I had to sit down after my daily job only to keep schedules I would
have given up long ago.

But I guess this is similar for every project not sponsored by a company
- what might happen to Qt some day too.

Post by Thiago Macieira
All Qt libraries are first-party: they come from the Qt Project.

Do you believe it would make sense to develop a 3rd party library under
the hood of Qt Project ?

Uwe

[Thiago Macieira]

Post by Uwe Rathmann
Hi Thiago,
my interest is of course to benefit as much as possible from the ideas
and solutions of the Qt development
and I believe the best way should be to organize my code and build
environment like Qt libraries do.

Before that: why do you want to?

Post by Uwe Rathmann

Post by Thiago Macieira
1) where they are installed

I wouldn't install Qwt into the same place where Qt is, because it works
with different binary compatible installations of Qt.
But of course it would be possible to do so for the same reasons you do
it with a module like Qt SVG.

If installing in the same place as Qt -- mandatorily -- helps you by
simplifying the way that the library is found, then by all means do it. If you
enforce that, you don't need to do any finding, since it's always found next to
the QtCore for example.

Post by Uwe Rathmann

Post by Thiago Macieira
2) whether they use qt_module_config.prf or equivalent or a future replacement

I'm not sure if this would be possible for code outside the Qt source tree ?

Highly not recommended: private API, we might change it at any time.

Post by Uwe Rathmann

Post by Thiago Macieira
3) whether they follow Qt conding conventions -- including headers and
macros to be used, like QT_STATIC

I have the same code base for Qt4 and Qt5 ( like the creator ) what
might require some extra ifdefs, but in general it should be possible -
as long as I'm aware of existing conventions.

Why do you want to?

Post by Uwe Rathmann

Post by Thiago Macieira
4) library and API naming

similar to 4.

Post by Thiago Macieira
5) development workflow and other Qt Project rules

I don't believe, that I could develop in the same release cycles as the
Qt library itself ( f.e I have no idea yet what it means to adopt Qwt to
QML )

Release cycles are not part of the Qt Project rules. Each Qt module decides
when to make releases and when not to. The Qt Project will make an overarching
release containing the latest tested of each module, though.

The rules I'm referring to are:
- developing in Gerrit, bugs in JIRA
- following the Maintainer / Approver workflow
- same spirit fit and technical fit guidelines

Post by Uwe Rathmann
The only reason why I'm doing the Qwt project for such a long time ( >
10 years ) is because I only do it when I like to.
If I had to sit down after my daily job only to keep schedules I would
have given up long ago.
But I guess this is similar for every project not sponsored by a company
- what might happen to Qt some day too.

Post by Thiago Macieira
All Qt libraries are first-party: they come from the Qt Project.

Do you believe it would make sense to develop a 3rd party library under
the hood of Qt Project ?

That's self-contradictory. If it's under Qt Project, it's first party by
definition.

Both Qwt and Qxt would be welcome, just as Phonon once was and still is. I'd
prefer to see a full API review, just as what we did for some kdecore classes
that moved into Qt, but we can apply the rule of Qt4 compatibility too.

What the maintainership load will be, only you can tell. I really don't know
if those modules would attract attention and contributions, generating
reviewing load for you. I don't know whether the bug report rate would require
the Qt Project QA to require the Maintainer to take action (the maintainer is
responsible for the module being "always ready for beta" and the overarching
release requires the last released version to work with the all the other last
released versions).

So this is really up to you and the question is: do you want to?

There's no shame in being a 3rd party library. Qwt has made a name for itself
and can continue doing that.

[l***@nokia.com]

Post by Uwe Rathmann
Hi Thiago,
my interest is of course to benefit as much as possible from the ideas
and solutions of the Qt development
and I believe the best way should be to organize my code and build
environment like Qt libraries do.

Post by Thiago Macieira
1) where they are installed

I wouldn't install Qwt into the same place where Qt is, because it works
with different binary compatible installations of Qt.
But of course it would be possible to do so for the same reasons you do
it with a module like Qt SVG.

Post by Thiago Macieira
2) whether they use qt_module_config.prf or equivalent or a future
replacement

I'm not sure if this would be possible for code outside the Qt source
tree ?

The Qt source tree is modularized, so there shouldn't be a difference for
Qwt.

Post by Uwe Rathmann

Post by Thiago Macieira
3) whether they follow Qt conding conventions -- including headers and
macros
to be used, like QT_STATIC

I have the same code base for Qt4 and Qt5 ( like the creator ) what
might require some extra ifdefs, but in general it should be possible -
as long as I'm aware of existing conventions.

Post by Thiago Macieira
4) library and API naming

similar to 4.

Post by Thiago Macieira
5) development workflow and other Qt Project rules

I don't believe, that I could develop in the same release cycles as the
Qt library itself ( f.e I have no idea yet what it means to adopt Qwt to
QML )

Q add-ons don't need to be released in the same cycle. I think that
definition might fit nicely to Qwt :)

Post by Uwe Rathmann
The only reason why I'm doing the Qwt project for such a long time ( >
10 years ) is because I only do it when I like to.
If I had to sit down after my daily job only to keep schedules I would
have given up long ago.
But I guess this is similar for every project not sponsored by a company
- what might happen to Qt some day too.

Post by Thiago Macieira
All Qt libraries are first-party: they come from the Qt Project.

Do you believe it would make sense to develop a 3rd party library under
the hood of Qt Project ?

We also now have projects such as PySide hosted on qt-project.

Look at the definition of a Qt add-on. I think that might fit nicely for
Qwt. In any case, if you want your library do live under the qt-project
umbrella we can most likely find a solution.

Cheers,
Lars