[Qt-interest] subclassing Sql drivers (linking issue)

[Thiago Macieira]

Em Terça-feira 23 Fevereiro 2010, às 17:27:22, Andre Somers escreveu:
> Thiago Macieira wrote:
> > Em Terça-feira 23 Fevereiro 2010, às 16:22:28, Andre Somers escreveu:
> >> Andre Somers wrote:
> >>> Andre Somers wrote:
> >>>> Hi,
> >>>> 
> >>>> I am trying to extend the Qt SQL drivers to add some functionality. I
> >>>> have the thing compiling, but I run into a problem when linking. I get
> > 
> >>>> lots of "undefined reference" errors like these:
> > Change Qt code and recompile the driver.
> > 
> > The driver is not a library. You cannot link to it.
> 
> Weird, since the project file says it is:
> 
> odbc.pro sets the target, and includes qsqldriverbase.pri
> sqldriverbase.pri includes qpluginbase.pri
> qpluginbase.pri contains TEMPLATE = lib
> 
> That would suggest that the driver *is* a lib. The mere fact that it
> results in a .dll (on windows) also suggests this.

Not really. It's not a library, it's a plugin.

In all platforms Qt supports, libraries and plugins are both dynamically-
loadable libraries (DLL, dylib) / shared objects (so) -- it's the same concept 
with different names. (The only one where it wasn't the case was Mac OS X 10.2 
and earlier, but those are not supported)

The difference between a library and a plugin is the interface that they 
export. Especially on Windows, where no symbols are exported unless explicitly 
marked so (__declspec(dllexport)).

For a library, besides the DLL you're going to find headers installed, which 
contain the public interface of that library. All such classes are properly 
exported (Q_CORE_EXPORT, Q_GUI_EXPORT, etc.) and usually documented. The same 
applies to your libraries as well, if you're on Windows -- on other platforms, 
qmake doesn't impose this on you.

For a plugin, however, there are no public headers. The classes are not 
exported, so the DLL's symbol table is almost empty. What it will contain, 
however, is a simple "plugin entry point": a C function that can be found via 
dlsym or GetProcAddress. The plugin loader code will then call that function 
and obtain an object that can be used (for Qt plugins, the plugin "instance").

A plugin usually implements an interface defined in a library. The Qt SQL 
drivers, for example, all derive from QSqlDriver. The rest of the code 
interacts with the plugin only by the interface defined in this library.

Now, what I do find weird is that QtSql has headers for each plugin. Some of 
the classes are exported, some aren't. And none of them is documented. I'm 
wondering if those headers should be _p.h and not made public.

Bill, do you have an opinion?

> Still, I managed to solve this a bit less elegantly by including the
> relevant parts of these .pro files into my own one, pulling in the Qt
> driver code into my own drivers. This frees me from having to re-modify
> the qt drivers time and time again with each qt version. At least as
> long as their .pro files remain stable... At least the thing compiles
> and links now, and the qt plugin mechanism seems to load the driver OK.
> Next up is making sure it actually works of course...

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100223/574f77b1/attachment.bin