Is it possible to create a dll without dllexport?

kshegunov

As the title already almost says, is it possible to create a dll without explicit dllexport?

If I remember correctly, if you don't export anything the linker will not generate any code (thus no dll).

The only explanation I have at the moment is that a dynamic lib is default for "TEMPLATE=LIB"

It is. If you don't put "CONFIG += static" qmake will generate a makefile that compiles into a dynamic library.

However, I thought that I would need also the macro "DLL_MAIN_SHARED_EXPORT" mimic for actually creating a dll.

I don't follow. You don't export from static libraries in the first place. A static library has no notion of visibility, it doesn't have a header or any way to load dependencies. It's only a collection of translation units (object files). So exporting/importing is not relevant to static libraries at all.

Kind regards.

koahnig

@Chris-Kawa said:

TEMPLATE = lib creates a dynamic shared library (lib+dll) by default. To make a static library (lib) you need to pass CONFIG += staticlib in the .pro of your library.

@kshegunov

I can live with that, but why should I handle an additional include file?

Just created a new lib project called "testDll" and 4 files are created plus .pro.user. Those files are:
TestDll.cpp

#include "TestDll.h"
TestDll::TestDll()
{
}

TestDll.h

#ifndef TESTDLL_H
#define TESTDLL_H
#include "testdll_global.h"
class TESTDLLSHARED_EXPORT TestDll
{
public:
    TestDll();
};
#endif // TESTDLL_H

testdll_global.h

#ifndef TESTDLL_GLOBAL_H
#define TESTDLL_GLOBAL_H
#include <QtCore/qglobal.h>
#if defined(TESTDLL_LIBRARY)
#  define TESTDLLSHARED_EXPORT Q_DECL_EXPORT
#else
#  define TESTDLLSHARED_EXPORT Q_DECL_IMPORT
#endif
#endif // TESTDLL_GLOBAL_H

and the TestDll.pro

#-------------------------------------------------
#
# Project created by QtCreator 2016-06-12T20:32:38
#
#-------------------------------------------------
QT       -= gui

TARGET = testDll
TEMPLATE = lib

DEFINES += TESTDLL_LIBRARY

SOURCES += TestDll.cpp

HEADERS += TestDll.h\
        testdll_global.h
unix {
    target.path = /usr/lib
    INSTALLS += target
}

My conclusion was that I need to have always the "testdll_global.h" and the macro "TESTDLLSHARED_EXPORT" in every header and every class declared which I like to export to the dll.

koahnig

To add to previous post:
The new conclusion would be that one can save quite a bit of work when ignoring the "testdll_global.h" and the macro "TESTDLLSHARED_EXPORT" stuff.
So why is that stuff added in the project template, if I do not need to have it at least with Qt?

Chris Kawa

@koahnig said:

Just created a new lib project called "testDll" and 4 files are created plus .pro.user.

Note that the wizard lets you choose the type of the project. The default is "Shared Library" i.e. a DLL. That is what you got and for that the macros are required.

The other settings in the wizard are "Statically Linked Library" and "Qt Plugin". The statically linked library has only two files - a .h/.cpp of your class without the extra export/import macros.

koahnig

@Chris-Kawa said:

@koahnig said:

Just created a new lib project called "testDll" and 4 files are created plus .pro.user.

Note that the wizard lets you choose the type of the project. The default is "Shared Library" i.e. a DLL. That is what you got and for that the macros are required.

The other settings in the wizard are "Statically Linked Library" and "Qt Plugin". The statically linked library has only two files - a .h/.cpp of your class without the extra export/import macros.

Agreed and all this is fine, but actually one can create a dll without using "testdll_global.h".

Possibly our posts crossed:
@koahnig said:

To add to previous post:
The new conclusion would be that one can save quite a bit of work when ignoring the "testdll_global.h" and the macro "TESTDLLSHARED_EXPORT" stuff.
So why is that stuff added in the project template, if I do not need to have it at least with Qt?

Basically there is my issue, why shall I add an include not required?

It looks logical to have the include "testdll_global.h", because it makes the look compatible to the typical things you have to do for creating a dll. However, as long as you stay within the Qt world it is additional work which is not required?

Chris Kawa

@koahnig said:

However, as long as you stay within the Qt world it is additional work which is not required?

It has nothing to do with Qt.
For a dynamically linked library you do need the import/export stuff, at least if you want to behave nicely. If you try it with MSVC you will see that your symbols are not visible if you don't export them.

The thing you experience is a weirdness of GCC (or MinGW in this case). It has this weird behavior that if you don't export anything explicitly it will export everything (sic!). I'm guessing it's to keep libraries that didn't have MSVC in mind working. As soon as you export any symbol the MSVC-like behavior kicks in and only those symbols declared as export will be exported.

To test that try to build your lib without any symbols exported (comment out the macros). Use DependencyWalker to examine the library - note that everytihing is exported. Now add this single export in your header: ___declspec( dllexport ) int foo; and inspect the library again - only foo is exported.

koahnig

@Chris-Kawa said:

The thing you experience is a weirdness of GCC (or MinGW in this case). It has this weird behavior that if you don't export anything explicitly it will export everything (sic!). I'm guessing it's to keep libraries that didn't have MSVC in mind working. As soon as you export any symbol the MSVC-like behavior kicks in and only those symbols declared as export will be exported.

OK, that is the explanation I was looking for.
I thought already right from the beginning that this might have something to do with MinGW. However, assuming such weirdness right away is typically not a good choice. Similar to assuming it is a compiler error if you do not find something right away.

Thanks a lot for confirmation. I was trying to find a note somewhere, but I could not.

kshegunov

@Chris-Kawa

It has nothing to do with Qt.

Nor with C++ actually. These things are OS specific and depend on the implementation of the linker/loader and the ABI.

I'm guessing it's to keep libraries that didn't have MSVC in mind working.

Most probably, yes. This is the default behavior on Linux - everything is exported by default, so I would assume this is to "facilitate" porting from *nix to windows.

@koahnig

Basically there is my issue, why shall I add an include not required?

As Chris said, it might not be an include file, but you do need the linkage specifiers.

koahnig

@kshegunov

That makes sense.

I have added the import/export stuff in the mean time. So basically all is broadened to hopefully all compilers and OSs. ;)

kshegunov

@koahnig

So basically all is broadened to hopefully all compilers and OSs.

It should be. To be honest, this default exporting behavior is one of the more suspicious decisions in Linux. Windows' way of enforcing symbols to be hidden by default (like we have with classes' members) is much more logical. I actually define two macros when making shared libraries - one that is for the export/import and one that forces symbols not explicitly exported to be hidden on Linux, thus getting a similar binary interface on all platforms; like done here.

Kind regards.