Qt-interest Archive, June 2007
Link imageformat plugins statically
Message 1 in thread
Hi All,
We deploy Qt as a shared library. Our application makes use of the
jpeg plugin, and we are able to get it to load in most cases.
However, there is a known (by Trolltech) issue with the plugin not
loading under some OS configurations. The work-around (we were told
by Qt support) is to include the Visual Studio DLLs (msv*.dll) and a
VS manifest file in all the plugin directories. This seemed to be
working for us in most cases, but it does not work on a clean 64-bit
XP system. We have been unable to get the jpeg plugin to load.
After another round of emails with support, we were told to "link in
the jpeg plugin into the application." and to use the "Q_IMPORT_PLUGIN
directive" according to
<http://doc.trolltech.com/4.3/plugins-howto.html#static-plugins>
I seem to get link errors when following the instructions on this doc.
We are not using a .pro file (so I can't set QTPLUGIN += qjpeg),
but I added the imageformats dir to our lib path and added qjpeg1.lib
in our library list. I still get link errors.
Does anyone know if you can link the jpeg plugin statically if you are
linking Qt in shared mode? I'm awaiting a response to this question
from support, but thought it might be faster to contact the list :)
Thanks,
Kirby
--
[ signature omitted ]
Message 2 in thread
I'd try to link everything statically. I know this works when you want
to link to plugins statically (using Visual Studio 2003).
Btw. why qjpeg1.lib? for me its either (binary package) qjpeg4.lib or
(built manually, which is needed for statically linking Qt) qjpeg.lib
(P.S. did anyone understand why the libs in the binary package are named
differently? it's just a hassle imho)
Cheers,
Peter
> We deploy Qt as a shared library. Our application makes use of the
> jpeg plugin, and we are able to get it to load in most cases.
> However, there is a known (by Trolltech) issue with the plugin not
> loading under some OS configurations. The work-around (we were told
> by Qt support) is to include the Visual Studio DLLs (msv*.dll) and a
> VS manifest file in all the plugin directories. This seemed to be
> working for us in most cases, but it does not work on a clean 64-bit
> XP system. We have been unable to get the jpeg plugin to load.
>
> After another round of emails with support, we were told to "link in
> the jpeg plugin into the application." and to use the "Q_IMPORT_PLUGIN
> directive" according to
> <http://doc.trolltech.com/4.3/plugins-howto.html#static-plugins>
>
> I seem to get link errors when following the instructions on this doc.
> We are not using a .pro file (so I can't set QTPLUGIN += qjpeg),
> but I added the imageformats dir to our lib path and added qjpeg1.lib
> in our library list. I still get link errors.
>
> Does anyone know if you can link the jpeg plugin statically if you are
> linking Qt in shared mode? I'm awaiting a response to this question
> from support, but thought it might be faster to contact the list :)
>
> Thanks,
> Kirby
--
[ signature omitted ]
Message 3 in thread
Thanks for the response.
We would like to keep Qt linked statically so we can share Qt with
other applications of ours.
It's qjpeg1.lib if you build Qt shared. If you build it statically,
it's qjpeg.lib. I've tried both, but get link errors in both cases.
When I link to the non-static plugin, I get the following link errors:
main.obj : error LNK2019: unresolved external symbol "class QObject *
__cdecl qt_plugin_instance_qjpeg(void)"
(?qt_plugin_instance_qjpeg@@YAPAVQObject@@XZ) referenced in function
"public: __thiscall
StaticqjpegPluginInstance::StaticqjpegPluginInstance(void)"
(??0StaticqjpegPluginInstance@@QAE@XZ)
C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.exe
: fatal error LNK1120: 1 unresolved externals
When I link to the static plugin, I get the following link errors:
qjpeg.lib(main.obj) : error LNK2005: "public: __thiscall
QString::QString(class QString const &)" (??0QString@@QAE@ABV0@@Z)
already defined in QtCore4.lib(QtCore4.dll)
qjpeg.lib(main.obj) : error LNK2005: "public: __thiscall
QString::~QString(void)" (??1QString@@QAE@XZ) already defined in
QtCore4.lib(QtCore4.dll)
qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
QByteArray::~QByteArray(void)" (??1QByteArray@@QAE@XZ) already defined
in QtCore4.lib(QtCore4.dll)
qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
QString::QString(void)" (??0QString@@QAE@XZ) already defined in
QtCore4.lib(QtCore4.dll)
qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
QString::~QString(void)" (??1QString@@QAE@XZ) already defined in
QtCore4.lib(QtCore4.dll)
qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: class QBool
__thiscall QString::contains(class QString const &,enum
Qt::CaseSensitivity)const "
(?contains@QString@@QBE?AVQBool@@ABV1@W4CaseSensitivity@Qt@@@Z)
already defined in QtCore4.lib(QtCore4.dll)
qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: bool __thiscall
QString::operator==(char const *)const " (??8QString@@QBE_NPBD@Z)
already defined in QtCore4.lib(QtCore4.dll)
qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: bool __thiscall
QString::operator!=(char const *)const " (??9QString@@QBE_NPBD@Z)
already defined in QtCore4.lib(QtCore4.dll)
qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
QVariant::QVariant(void)" (??0QVariant@@QAE@XZ) already defined in
QtCore4.lib(QtCore4.dll)
QtCore4.lib(QtCore4.dll) : error LNK2005: "public: char * __thiscall
QByteArray::data(void)" (?data@QByteArray@@QAEPADXZ) already defined
in qjpeg.lib(qjpeghandler.obj)
QtCore4.lib(QtCore4.dll) : error LNK2005: "public: __thiscall
QByteArray::QByteArray(void)" (??0QByteArray@@QAE@XZ) already defined
in qjpeg.lib(qjpeghandler.obj)
Creating library
C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.lib
and object C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.exp
qjpeg.lib(main.obj) : error LNK2019: unresolved external symbol
"public: static struct QListData::Data QListData::shared_null";
(?shared_null@QListData@@2UData@1@A) referenced in function "public:
__thiscall QList<class QString>::QList<class QString>(void)"
(??0?$QList@VQString@@@@QAE@XZ)
qjpeg.lib(qjpeghandler.obj) : error LNK2019: unresolved external
symbol "private: static struct QByteArray::Data
QByteArray::shared_null" (?shared_null@QByteArray@@0UData@1@A)
referenced in function "public: __thiscall
QByteArray::QByteArray(void)" (??0QByteArray@@QAE@XZ)
qjpeg.lib(qjpeghandler.obj) : error LNK2019: unresolved external
symbol "private: static struct QString::Data QString::shared_null"
(?shared_null@QString@@0UData@1@A) referenced in function "public:
__thiscall QString::QString(void)" (??0QString@@QAE@XZ)
qjpeg.lib(qjpeghandler.obj) : error LNK2019: unresolved external
symbol "private: static class QTextCodec * QString::codecForCStrings"
(?codecForCStrings@QString@@0PAVQTextCodec@@A) referenced in function
"bool __cdecl qStringComparisonHelper(class QString const &,char const
*)" (?qStringComparisonHelper@@YA_NABVQString@@PBD@Z)
C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.exe
: fatal error LNK1120: 4 unresolved externals
On 6/25/07, Peter Prade <prade@xxxxxxxxxxx> wrote:
> I'd try to link everything statically. I know this works when you want
> to link to plugins statically (using Visual Studio 2003).
>
> Btw. why qjpeg1.lib? for me its either (binary package) qjpeg4.lib or
> (built manually, which is needed for statically linking Qt) qjpeg.lib
> (P.S. did anyone understand why the libs in the binary package are named
> differently? it's just a hassle imho)
>
> Cheers,
> Peter
>
> > We deploy Qt as a shared library. Our application makes use of the
> > jpeg plugin, and we are able to get it to load in most cases.
> > However, there is a known (by Trolltech) issue with the plugin not
> > loading under some OS configurations. The work-around (we were told
> > by Qt support) is to include the Visual Studio DLLs (msv*.dll) and a
> > VS manifest file in all the plugin directories. This seemed to be
> > working for us in most cases, but it does not work on a clean 64-bit
> > XP system. We have been unable to get the jpeg plugin to load.
> >
> > After another round of emails with support, we were told to "link in
> > the jpeg plugin into the application." and to use the "Q_IMPORT_PLUGIN
> > directive" according to
> > <http://doc.trolltech.com/4.3/plugins-howto.html#static-plugins>
> >
> > I seem to get link errors when following the instructions on this doc.
> > We are not using a .pro file (so I can't set QTPLUGIN += qjpeg),
> > but I added the imageformats dir to our lib path and added qjpeg1.lib
> > in our library list. I still get link errors.
> >
> > Does anyone know if you can link the jpeg plugin statically if you are
> > linking Qt in shared mode? I'm awaiting a response to this question
> > from support, but thought it might be faster to contact the list :)
> >
> > Thanks,
> > Kirby
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 4 in thread
I should say, in both cases I'm linking to the shared Qt libs (core, gui, xml).
On 6/25/07, Kirby Frugia <hpkirby@xxxxxxxxx> wrote:
> Thanks for the response.
>
> We would like to keep Qt linked statically so we can share Qt with
> other applications of ours.
>
> It's qjpeg1.lib if you build Qt shared. If you build it statically,
> it's qjpeg.lib. I've tried both, but get link errors in both cases.
> When I link to the non-static plugin, I get the following link errors:
> main.obj : error LNK2019: unresolved external symbol "class QObject *
> __cdecl qt_plugin_instance_qjpeg(void)"
> (?qt_plugin_instance_qjpeg@@YAPAVQObject@@XZ) referenced in function
> "public: __thiscall
> StaticqjpegPluginInstance::StaticqjpegPluginInstance(void)"
> (??0StaticqjpegPluginInstance@@QAE@XZ)
> C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.exe
> : fatal error LNK1120: 1 unresolved externals
>
> When I link to the static plugin, I get the following link errors:
> qjpeg.lib(main.obj) : error LNK2005: "public: __thiscall
> QString::QString(class QString const &)" (??0QString@@QAE@ABV0@@Z)
> already defined in QtCore4.lib(QtCore4.dll)
> qjpeg.lib(main.obj) : error LNK2005: "public: __thiscall
> QString::~QString(void)" (??1QString@@QAE@XZ) already defined in
> QtCore4.lib(QtCore4.dll)
> qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
> QByteArray::~QByteArray(void)" (??1QByteArray@@QAE@XZ) already defined
> in QtCore4.lib(QtCore4.dll)
> qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
> QString::QString(void)" (??0QString@@QAE@XZ) already defined in
> QtCore4.lib(QtCore4.dll)
> qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
> QString::~QString(void)" (??1QString@@QAE@XZ) already defined in
> QtCore4.lib(QtCore4.dll)
> qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: class QBool
> __thiscall QString::contains(class QString const &,enum
> Qt::CaseSensitivity)const "
> (?contains@QString@@QBE?AVQBool@@ABV1@W4CaseSensitivity@Qt@@@Z)
> already defined in QtCore4.lib(QtCore4.dll)
> qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: bool __thiscall
> QString::operator==(char const *)const " (??8QString@@QBE_NPBD@Z)
> already defined in QtCore4.lib(QtCore4.dll)
> qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: bool __thiscall
> QString::operator!=(char const *)const " (??9QString@@QBE_NPBD@Z)
> already defined in QtCore4.lib(QtCore4.dll)
> qjpeg.lib(qjpeghandler.obj) : error LNK2005: "public: __thiscall
> QVariant::QVariant(void)" (??0QVariant@@QAE@XZ) already defined in
> QtCore4.lib(QtCore4.dll)
> QtCore4.lib(QtCore4.dll) : error LNK2005: "public: char * __thiscall
> QByteArray::data(void)" (?data@QByteArray@@QAEPADXZ) already defined
> in qjpeg.lib(qjpeghandler.obj)
> QtCore4.lib(QtCore4.dll) : error LNK2005: "public: __thiscall
> QByteArray::QByteArray(void)" (??0QByteArray@@QAE@XZ) already defined
> in qjpeg.lib(qjpeghandler.obj)
> Creating library
> C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.lib
> and object C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.exp
> qjpeg.lib(main.obj) : error LNK2019: unresolved external symbol
> "public: static struct QListData::Data QListData::shared_null";
> (?shared_null@QListData@@2UData@1@A) referenced in function "public:
> __thiscall QList<class QString>::QList<class QString>(void)"
> (??0?$QList@VQString@@@@QAE@XZ)
> qjpeg.lib(qjpeghandler.obj) : error LNK2019: unresolved external
> symbol "private: static struct QByteArray::Data
> QByteArray::shared_null" (?shared_null@QByteArray@@0UData@1@A)
> referenced in function "public: __thiscall
> QByteArray::QByteArray(void)" (??0QByteArray@@QAE@XZ)
> qjpeg.lib(qjpeghandler.obj) : error LNK2019: unresolved external
> symbol "private: static struct QString::Data QString::shared_null"
> (?shared_null@QString@@0UData@1@A) referenced in function "public:
> __thiscall QString::QString(void)" (??0QString@@QAE@XZ)
> qjpeg.lib(qjpeghandler.obj) : error LNK2019: unresolved external
> symbol "private: static class QTextCodec * QString::codecForCStrings"
> (?codecForCStrings@QString@@0PAVQTextCodec@@A) referenced in function
> "bool __cdecl qStringComparisonHelper(class QString const &,char const
> *)" (?qStringComparisonHelper@@YA_NABVQString@@PBD@Z)
> C:\workspace\head\hurricane-sw-development\activities\hurricane\Release\TemplateLabeler.exe
> : fatal error LNK1120: 4 unresolved externals
>
> On 6/25/07, Peter Prade <prade@xxxxxxxxxxx> wrote:
> > I'd try to link everything statically. I know this works when you want
> > to link to plugins statically (using Visual Studio 2003).
> >
> > Btw. why qjpeg1.lib? for me its either (binary package) qjpeg4.lib or
> > (built manually, which is needed for statically linking Qt) qjpeg.lib
> > (P.S. did anyone understand why the libs in the binary package are named
> > differently? it's just a hassle imho)
> >
> > Cheers,
> > Peter
> >
> > > We deploy Qt as a shared library. Our application makes use of the
> > > jpeg plugin, and we are able to get it to load in most cases.
> > > However, there is a known (by Trolltech) issue with the plugin not
> > > loading under some OS configurations. The work-around (we were told
> > > by Qt support) is to include the Visual Studio DLLs (msv*.dll) and a
> > > VS manifest file in all the plugin directories. This seemed to be
> > > working for us in most cases, but it does not work on a clean 64-bit
> > > XP system. We have been unable to get the jpeg plugin to load.
> > >
> > > After another round of emails with support, we were told to "link in
> > > the jpeg plugin into the application." and to use the "Q_IMPORT_PLUGIN
> > > directive" according to
> > > <http://doc.trolltech.com/4.3/plugins-howto.html#static-plugins>
> > >
> > > I seem to get link errors when following the instructions on this doc.
> > > We are not using a .pro file (so I can't set QTPLUGIN += qjpeg),
> > > but I added the imageformats dir to our lib path and added qjpeg1.lib
> > > in our library list. I still get link errors.
> > >
> > > Does anyone know if you can link the jpeg plugin statically if you are
> > > linking Qt in shared mode? I'm awaiting a response to this question
> > > from support, but thought it might be faster to contact the list :)
> > >
> > > Thanks,
> > > Kirby
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> > List archive and information: http://lists.trolltech.com/qt-interest/
> >
> >
>
--
[ signature omitted ]
Message 5 in thread
Yeah well, if you made a static Qt build, and link to qjpeg.lib, you
also need to link to the static versions of all the Qt libs (i.e.
QtCore.lib etc.)
Cheers,
Peter
> -----Original Message-----
> From: Kirby Frugia [mailto:hpkirby@xxxxxxxxx]
> Sent: Monday, June 25, 2007 8:18 PM
> To: Peter Prade
> Cc: qt-interest@xxxxxxxxxxxxx
> Subject: Re: Link imageformat plugins statically
>
> I should say, in both cases I'm linking to the shared Qt libs (core,
gui,
> xml).
>
> On 6/25/07, Kirby Frugia <hpkirby@xxxxxxxxx> wrote:
> > Thanks for the response.
> >
> > We would like to keep Qt linked statically so we can share Qt with
> > other applications of ours.
> >
> > It's qjpeg1.lib if you build Qt shared. If you build it statically,
> > it's qjpeg.lib. I've tried both, but get link errors in both cases.
> > When I link to the non-static plugin, I get the following link
errors:
> > main.obj : error LNK2019: unresolved external symbol "class QObject
*
> > __cdecl qt_plugin_instance_qjpeg(void)"
> > (?qt_plugin_instance_qjpeg@@YAPAVQObject@@XZ) referenced in function
> > "public: __thiscall
> > StaticqjpegPluginInstance::StaticqjpegPluginInstance(void)"
> > (??0StaticqjpegPluginInstance@@QAE@XZ)
> > C:\workspace\head\hurricane-sw-
> development\activities\hurricane\Release\TemplateLabeler.exe
> > : fatal error LNK1120: 1 unresolved externals
> >
> > When I link to the static plugin, I get the following link errors:
> > qjpeg.lib(main.obj) : error LNK2005: "public: __thiscall
> > QString::QString(class QString const &)" (??0QString@@QAE@ABV0@@Z)
> > already defined in QtCore4.lib(QtCore4.dll)
--
[ signature omitted ]
Message 6 in thread
So that means that Trolltech's "solution" for this issue is to link
everything statically...since the plugin won't load dynamically under
certain conditions. That does not seem like a good solution to me
since it essentially means we can't have a shared deployment that will
work in all cases. Ugg.
Hopefully I hear better news when support responds...
On 6/25/07, Peter Prade <prade@xxxxxxxxxxx> wrote:
> Yeah well, if you made a static Qt build, and link to qjpeg.lib, you
> also need to link to the static versions of all the Qt libs (i.e.
> QtCore.lib etc.)
>
> Cheers,
> Peter
>
> > -----Original Message-----
> > From: Kirby Frugia [mailto:hpkirby@xxxxxxxxx]
> > Sent: Monday, June 25, 2007 8:18 PM
> > To: Peter Prade
> > Cc: qt-interest@xxxxxxxxxxxxx
> > Subject: Re: Link imageformat plugins statically
> >
> > I should say, in both cases I'm linking to the shared Qt libs (core,
> gui,
> > xml).
> >
> > On 6/25/07, Kirby Frugia <hpkirby@xxxxxxxxx> wrote:
> > > Thanks for the response.
> > >
> > > We would like to keep Qt linked statically so we can share Qt with
> > > other applications of ours.
> > >
> > > It's qjpeg1.lib if you build Qt shared. If you build it statically,
> > > it's qjpeg.lib. I've tried both, but get link errors in both cases.
> > > When I link to the non-static plugin, I get the following link
> errors:
> > > main.obj : error LNK2019: unresolved external symbol "class QObject
> *
> > > __cdecl qt_plugin_instance_qjpeg(void)"
> > > (?qt_plugin_instance_qjpeg@@YAPAVQObject@@XZ) referenced in function
> > > "public: __thiscall
> > > StaticqjpegPluginInstance::StaticqjpegPluginInstance(void)"
> > > (??0StaticqjpegPluginInstance@@QAE@XZ)
> > > C:\workspace\head\hurricane-sw-
> > development\activities\hurricane\Release\TemplateLabeler.exe
> > > : fatal error LNK1120: 1 unresolved externals
> > >
> > > When I link to the static plugin, I get the following link errors:
> > > qjpeg.lib(main.obj) : error LNK2005: "public: __thiscall
> > > QString::QString(class QString const &)" (??0QString@@QAE@ABV0@@Z)
> > > already defined in QtCore4.lib(QtCore4.dll)
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 7 in thread
On 25/06/07, Kirby Frugia <hpkirby@xxxxxxxxx> wrote:
> So that means that Trolltech's "solution" for this issue is to link
> everything statically...since the plugin won't load dynamically under
> certain conditions. That does not seem like a good solution to me
> since it essentially means we can't have a shared deployment that will
> work in all cases. Ugg.
>
> Hopefully I hear better news when support responds...
Even if support responds differently, I can tell you from experience
that certain GNU/Linux distribution vendors will not support mixed
static/shared linking in programs.
I used to distribute an application that was built for/on RedHat
Linux. I filed a bug I encountered when trying to dlopen() shared
libraries from a statically linked executable. I was told in so many
words that I was stupid for even trying such a thing.
Caveat emptor.
--
[ signature omitted ]
Message 8 in thread
Thanks for the info. It just seemed to me that this was exactly what
TrollTech was suggesting for us to do. They did not mention
rebuilding Qt statically, but instead only mentioned building the
plugin into the application. I would much rather do an entirely
shared deployment, but am unable to due to the bug in the jpeg loading
(whether it's an MS or a Trolltech issue).
On 6/25/07, Shawn Walker <binarycrusader@xxxxxxxxx> wrote:
> On 25/06/07, Kirby Frugia <hpkirby@xxxxxxxxx> wrote:
> > So that means that Trolltech's "solution" for this issue is to link
> > everything statically...since the plugin won't load dynamically under
> > certain conditions. That does not seem like a good solution to me
> > since it essentially means we can't have a shared deployment that will
> > work in all cases. Ugg.
> >
> > Hopefully I hear better news when support responds...
>
> Even if support responds differently, I can tell you from experience
> that certain GNU/Linux distribution vendors will not support mixed
> static/shared linking in programs.
>
> I used to distribute an application that was built for/on RedHat
> Linux. I filed a bug I encountered when trying to dlopen() shared
> libraries from a statically linked executable. I was told in so many
> words that I was stupid for even trying such a thing.
>
> Caveat emptor.
>
> --
> "Less is only more where more is no good." --Frank Lloyd Wright
>
> Shawn Walker, Software and Systems Analyst
> binarycrusader@xxxxxxxxx - http://binarycrusader.blogspot.com/
>
--
[ signature omitted ]
Message 9 in thread
Kirby Frugia wrote:
> Thanks for the info. It just seemed to me that this was exactly what
> TrollTech was suggesting for us to do. They did not mention
> rebuilding Qt statically, but instead only mentioned building the
> plugin into the application.
Personally I'd expect that to be fine. It sounds to me like this:
>> I used to distribute an application that was built for/on RedHat
>> Linux. I filed a bug I encountered when trying to dlopen() shared
>> libraries from a statically linked executable. I was told in so many
>> words that I was stupid for even trying such a thing.
refers to runtime dynamic linking in a wholly statically linked app. I
can see why that might not work, since you won't have ld.so available.
It's not stupid to try it, but it's not surprising it won't work. You
just have to build a dynamic executable with all libraries except libc
and ld.so statically linked and it'll work just fine, though. Since
modern glibc on Linux barely supports static linking at all and (AFAIK)
relies on being able to dynamically load modules for nss services etc,
it's a good idea anyway.
You, on the other hand, are building a dynamic executable and statically
linking a library into it. I can't say it's going to work on all
platforms but it's certainly not the same thing the last reply was
talking about.
Do all platforms really permit a shared library to resolve symbols from
the main executable, though? I'm pretty sure I remember having problems
with exactly this on Mac OS X.
--
[ signature omitted ]
Message 10 in thread
On 6/26/07, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >> I used to distribute an application that was built for/on RedHat
> >> Linux. I filed a bug I encountered when trying to dlopen() shared
> >> libraries from a statically linked executable. I was told in so many
> >> words that I was stupid for even trying such a thing.
>
> refers to runtime dynamic linking in a wholly statically linked app. I
> can see why that might not work, since you won't have ld.so available.
> It's not stupid to try it, but it's not surprising it won't work. You
> just have to build a dynamic executable with all libraries except libc
> and ld.so statically linked and it'll work just fine, though. Since
> modern glibc on Linux barely supports static linking at all and (AFAIK)
> relies on being able to dynamically load modules for nss services etc,
> it's a good idea anyway.
We are distributing a shared linked app with Qt compiled static into
the application on Linux, there is no problem with static compile of a
few libraries. Yes, the binary gets bigger but there are so much more
to it, we can distribute a single binary with embedded
images/files/etc... and we always knows what Qt version the app is
running which is thoroughly tested on before each release.
--
[ signature omitted ]
Message 11 in thread
Hello, Kirby Frugia
25.06.2007 23:47 you wrote:
> Hi All,
>
> We deploy Qt as a shared library. Our application makes use of the
> jpeg plugin, and we are able to get it to load in most cases.
> However, there is a known (by Trolltech) issue with the plugin not
> loading under some OS configurations. The work-around (we were told
> by Qt support) is to include the Visual Studio DLLs (msv*.dll) and a
> VS manifest file in all the plugin directories. This seemed to be
> working for us in most cases, but it does not work on a clean 64-bit
> XP system. We have been unable to get the jpeg plugin to load.
>
Have you tried using MS run-time merge module for your installation ?
--
[ signature omitted ]
Message 12 in thread
Hi.
If you still want to go the shared library route you can try to *remove*
the manifest (embedded as a resource) from the qjpeg plugin.
You can remove resources by just opening the dll with VS2005 ("Open With").
This should only require that the microsoft runtimes are in the same
folder as the executable.
This worked for me on a clean 32-bit windows XP, but I haven't tried it
on a clean 64-bit windows XP yet, but I see no reason why it should
behave differently.
I would be very grateful if you could report back to me on the result of
this :)
--
[ signature omitted ]
