Qt-interest Archive, August 2007
Hardcoded paths to Qt installation in various binaries(win-opensource/mingw).
Pages: Prev | 1 | 2 | 3 | Next
Message 16 in thread
> Well the OP claims that there are paths stored in the other executables
> which makes them unusable. But thats plain wrong. Yes there is another
> path always stored somewhere in the apps: The plugin installation path
> for Qt. However you can always add new paths to search for plugins using
> an environment variable, just as the API docs in
> QCoreApplication::libraryPaths() say. So the only real issue with
> "hardcoded paths in Qt executables" can be qmake when used for the
> buildsystem.
The hardcoded paths to QT are stored even inside the binaries of your
programs you build.
When I looked inside the .exe to figure yout why it is so large, I
found that absolute paths to QT installation is stored in it (which is
of course wrong, as the binary is shipped to other people - and they
probably won't have QT at all, especially not in the same directory as
me)
So either the path is not used (then why it is there?) or is is used
(and then it is wrong, as outside my machine it won't work)...
Martin Petricek
--
[ signature omitted ]
Message 17 in thread
> When I looked inside the .exe to figure yout why it is so large, I
> found that absolute paths to QT installation is stored in it (which is
> of course wrong, as the binary is shipped to other people - and they
> probably won't have QT at all, especially not in the same directory as
> me)
> So either the path is not used (then why it is there?) or is is used
> (and then it is wrong, as outside my machine it won't work)...
Are you really sure you looked at the _stripped_ windows binary? Looking
at the binary with debugging symbols will of course hold this information!
Regards,
Malte
--
[ signature omitted ]
Message 18 in thread
Yes, it was stripped binary.
I found strings like this:
qt_docspath=E:/qt4.3.0/doc
qt_hdrspath=E:/qt4.3.0/include
...
in the binary. I even found corresponding source file which contained
them, so they sure weren't any form of debugging info.
When compiling with QT4 static, they are in the .exe, when compiling
with dynamic linking, these strings end up in QtCore4.dll
Martin Petricek
On 8/27/07, Malte Witt <malte.witt@xxxxxxxxxxxxx> wrote:
> > When I looked inside the .exe to figure yout why it is so large, I
> > found that absolute paths to QT installation is stored in it (which is
> > of course wrong, as the binary is shipped to other people - and they
> > probably won't have QT at all, especially not in the same directory as
> > me)
> > So either the path is not used (then why it is there?) or is is used
> > (and then it is wrong, as outside my machine it won't work)...
>
> Are you really sure you looked at the _stripped_ windows binary? Looking
> at the binary with debugging symbols will of course hold this information!
>
> Regards,
> Malte
>
> --
> 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 19 in thread
On 08-27-2007 9:59 AM, "BH" wrote:
> Yes, it was stripped binary.
>
> I found strings like this:
> qt_docspath=E:/qt4.3.0/doc
> qt_hdrspath=E:/qt4.3.0/include
> ...
>
> in the binary. I even found corresponding source file which contained
> them, so they sure weren't any form of debugging info.
>
> When compiling with QT4 static, they are in the .exe, when compiling
> with dynamic linking, these strings end up in QtCore4.dll
>
> Martin Petricek
Assistant, in particular, has this problem. I currently cannot use Assistant
with 4.3.1 on the Mac because of a bug when it is built debug -static. So,
since 4.3.0 Assistant (mostly) worked, I tried copying it over to the 4.3.1
installation assuming that it would use the documentation in ../doc (or
$QTDIR/doc). WRONG! It uses the 4.3.0 documentation no matter where I put
it.
Hard-coding the path is a VERY BAD ASSUMPTION, and as a result, Assistant is
completely useless to me on the Mac until Trolltech fixes it.
Keith
**Please do not reply to me, reply to the list.**
--
[ signature omitted ]
Message 20 in thread
On 27.08.07 11:30:48, Keith Esau wrote:
> On 08-27-2007 9:59 AM, "BH" wrote:
>
> > Yes, it was stripped binary.
> >
> > I found strings like this:
> > qt_docspath=E:/qt4.3.0/doc
> > qt_hdrspath=E:/qt4.3.0/include
> > ...
> >
> > in the binary. I even found corresponding source file which contained
> > them, so they sure weren't any form of debugging info.
> >
> > When compiling with QT4 static, they are in the .exe, when compiling
> > with dynamic linking, these strings end up in QtCore4.dll
> >
> > Martin Petricek
>
> Assistant, in particular, has this problem. I currently cannot use Assistant
> with 4.3.1 on the Mac because of a bug when it is built debug -static. So,
> since 4.3.0 Assistant (mostly) worked, I tried copying it over to the 4.3.1
> installation assuming that it would use the documentation in ../doc (or
> $QTDIR/doc). WRONG! It uses the 4.3.0 documentation no matter where I put
> it.
>
> Hard-coding the path is a VERY BAD ASSUMPTION, and as a result, Assistant is
> completely useless to me on the Mac until Trolltech fixes it.
If they don't provide a mean to choose a different path that is very bad
indeed. Luckily TT is not stupid and provides you with such means. Ever
tried "assistant -help"? ;)
Just make sure you hit the reload button before checking which version
you see. It seems that assistant doesn't reload the page that was
displayed last time it was started.
Andreas
--
[ signature omitted ]
Message 21 in thread
On 08-27-2007 12:47 PM, "Andreas Pakulat" wrote:
> If they don't provide a mean to choose a different path that is very bad
> indeed. Luckily TT is not stupid and provides you with such means. Ever
> tried "assistant -help"? ;)
How do you add -help when launching on a GUI interface? (I double-click to
launch, I never use the command line for a GUI program. :) In particular,
you can't (easily) launch Assistant via the command line on the Mac because
the tool is buried inside of the Assistant.app folder (and the user is not
supposed to know where).
If I remember right, there was a setting in the Preferences in the 3.x
Assistant to specify where the doc pages were located. Too bad it was lost
in 4.x.
Keith
**Please do not reply to me, reply to the list.**
--
[ signature omitted ]
Message 22 in thread
On 27.08.07 13:57:59, Keith Esau wrote:
> On 08-27-2007 12:47 PM, "Andreas Pakulat" wrote:
>
> > If they don't provide a mean to choose a different path that is very bad
> > indeed. Luckily TT is not stupid and provides you with such means. Ever
> > tried "assistant -help"? ;)
>
> How do you add -help when launching on a GUI interface? (I double-click to
> launch, I never use the command line for a GUI program. :) In particular,
> you can't (easily) launch Assistant via the command line on the Mac because
> the tool is buried inside of the Assistant.app folder (and the user is not
> supposed to know where).
Hmm, yeah, you can't really do something about broken OS that doesn't
provide means to run apps from a shell huh ;)
I have no idea how this could be achieved on MacOS, doesn't Finder or
something like that allow to set parameters for the app inside the
bundle? To help you a bit: its -docpath /path/to/qt/doc (i.e. the folder
that contains the html folder and in that html the .dcf files).
> If I remember right, there was a setting in the Preferences in the 3.x
> Assistant to specify where the doc pages were located. Too bad it was lost
> in 4.x.
I suggest to open a bugreport for that, obviously its rather complicated
to do that on MacOS now..
Andreas
--
[ signature omitted ]
Message 23 in thread
Hello, Andreas Pakulat
27.08.2007 23:47 you wrote:
> If they don't provide a mean to choose a different path that is very bad
> indeed. Luckily TT is not stupid and provides you with such means. Ever
> tried "assistant -help"? ;)
>
Ever tried click "Home" button after changing docPath?
You can hit the reload button as many as you wish and get
"The page could not be found" every time.
--
[ signature omitted ]
Message 24 in thread
On 28.08.07 16:57:34, Nikolay Moskvichev wrote:
> Hello, Andreas Pakulat
> 27.08.2007 23:47 you wrote:
> >If they don't provide a mean to choose a different path that is very bad
> >indeed. Luckily TT is not stupid and provides you with such means. Ever
> >tried "assistant -help"? ;)
>
> Ever tried click "Home" button after changing docPath?
> You can hit the reload button as many as you wish and get
> "The page could not be found" every time.
I don't get a "the page could not be found", but I do have the proper
install dir. Anyway that clearly is a bug in assistant, the assistant,
linguist, designer and qmake manual buttons work perfectly fine with
docpath. You should report that to qt-bugs at trolltech
Andreas
--
[ signature omitted ]
Message 25 in thread
Hello, Andreas Pakulat
28.08.2007 23:17 you wrote:
>>
>> Ever tried click "Home" button after changing docPath?
>> You can hit the reload button as many as you wish and get
>> "The page could not be found" every time.
>
> I don't get a "the page could not be found", but I do have the proper
> install dir. Anyway that clearly is a bug in assistant, the assistant,
> linguist, designer and qmake manual buttons work perfectly fine with
> docpath. You should report that to qt-bugs at trolltech
>
Just wondering why similar functionality not implemented in qmake?
Something like "qtPath"?
There is registry key "HKEY_CURRENT_USER\Software\Trolltech", why not
store all needed patches here (as already done with plugins)?
--
[ signature omitted ]
Message 26 in thread
On 08-28-2007 9:29 PM, "Nikolay Moskvichev" wrote:
> Hello, Andreas Pakulat
> 28.08.2007 23:17 you wrote:
>>>
>>> Ever tried click "Home" button after changing docPath?
>>> You can hit the reload button as many as you wish and get
>>> "The page could not be found" every time.
>>
>> I don't get a "the page could not be found", but I do have the proper
>> install dir. Anyway that clearly is a bug in assistant, the assistant,
>> linguist, designer and qmake manual buttons work perfectly fine with
>> docpath. You should report that to qt-bugs at trolltech
>>
>
> Just wondering why similar functionality not implemented in qmake?
> Something like "qtPath"?
> There is registry key "HKEY_CURRENT_USER\Software\Trolltech", why not
> store all needed patches here (as already done with plugins)?
The registry affects ALL installations. Many developers need to be able to
switch between different versions. I have 4.2.3, 4.3.0 and 4.3.1 all
installed and need to be able to use any one of them, possibly
simultaneously in different cmd.exe windows. This is partly why Trolltech
removed dependence on QTDIR.
However, this does not make hard coding correct either. The paths qmake uses
(and the .conf files too) should be relative to its location.
Keith
**Please do not reply to me, reply to the list.**
--
[ signature omitted ]
Message 27 in thread
On 8/28/07, Gordon.Schumacher@xxxxxxxxxxx <Gordon.Schumacher@xxxxxxxxxxx> wrote:
> archimed7592@xxxxxxxxx wrote on 08/26/2007 02:03:43 AM:
>
> # 2. How can I solve my problem with path-independent development
> # environment now(with latest release: qt-4.3.1)? Is there any patcher,
> # that I can use when moving environment to another computer/another
> # path? Maybe I could create something like your installer
> # qt-win-opensource-4.3.1-mingw.exe?
>
> Ignoring, for the moment, whether or not this is a good idea:
> http://lists.trolltech.com/qt-interest/2005-11/thread00257-0.html
Thanks, my friend. I started this thread in hope, that patching
binaries myself is foolish and there is smart solution. But, as I can
see, developers from TT have endeavoured and made all for our
"comfort".
On 8/29/07, Keith Esau <keith.esau@xxxxxxx> wrote:
> On 08-28-2007 9:29 PM, "Nikolay Moskvichev" wrote:
>
> > Hello, Andreas Pakulat
> > 28.08.2007 23:17 you wrote:
> >>>
> >>> Ever tried click "Home" button after changing docPath?
> >>> You can hit the reload button as many as you wish and get
> >>> "The page could not be found" every time.
> >>
> >> I don't get a "the page could not be found", but I do have the proper
> >> install dir. Anyway that clearly is a bug in assistant, the assistant,
> >> linguist, designer and qmake manual buttons work perfectly fine with
> >> docpath. You should report that to qt-bugs at trolltech
> >>
> >
> > Just wondering why similar functionality not implemented in qmake?
> > Something like "qtPath"?
> > There is registry key "HKEY_CURRENT_USER\Software\Trolltech", why not
> > store all needed patches here (as already done with plugins)?
>
> The registry affects ALL installations. Many developers need to be able to
> switch between different versions. I have 4.2.3, 4.3.0 and 4.3.1 all
> installed and need to be able to use any one of them, possibly
> simultaneously in different cmd.exe windows. This is partly why Trolltech
> removed dependence on QTDIR.
>
> However, this does not make hard coding correct either. The paths qmake uses
> (and the .conf files too) should be relative to its location.
Dependence on the QTDIR is not as strong as on the registry.
What prevent you from creating 3 cmd files with similar content:
rem qt-4.2.3.cmd
set QTDIR=path/to/qt/4.2.3
cmd
rem qt-4.3.0.cmd
set QTDIR=path/to/qt/4.3.0
cmd
rem qt-4.3.1.cmd
set QTDIR=path/to/qt/4.3.1
cmd
Oh, I know: you can't do that because genius developers from TT made
great design decision: they removed support of QTDIR env var :angry:
--
[ signature omitted ]
Message 28 in thread
On 8/29/07, Vadim Doroginin <archimed7592+mailing@xxxxxxxxx> wrote:
> Dependence on the QTDIR is not as strong as on the registry.
> What prevent you from creating 3 cmd files with similar content:
>
> rem qt-4.2.3.cmd
> set QTDIR=path/to/qt/4.2.3
> cmd
>
> rem qt-4.3.0.cmd
> set QTDIR=path/to/qt/4.3.0
> cmd
>
> rem qt-4.3.1.cmd
> set QTDIR=path/to/qt/4.3.1
> cmd
>
> Oh, I know: you can't do that because genius developers from TT made
> great design decision: they removed support of QTDIR env var :angry:
The qtvars.bat file generated by the Qt Windows installer does almost
exactly what you just described (it actually sets QTDIR, PATH, and
QMAKESPEC). It works just fine for keeping multiple versions of Qt on
a single Windows machine.
--
[ signature omitted ]
Message 29 in thread
On 8/30/07, Andrew Medico <a.medico@xxxxxxxxx> wrote:
> On 8/29/07, Vadim Doroginin <archimed7592+mailing@xxxxxxxxx> wrote:
>
> > Dependence on the QTDIR is not as strong as on the registry.
> > What prevent you from creating 3 cmd files with similar content:
> >
> > rem qt-4.2.3.cmd
> > set QTDIR=path/to/qt/4.2.3
> > cmd
> >
> > rem qt-4.3.0.cmd
> > set QTDIR=path/to/qt/4.3.0
> > cmd
> >
> > rem qt-4.3.1.cmd
> > set QTDIR=path/to/qt/4.3.1
> > cmd
> >
> > Oh, I know: you can't do that because genius developers from TT made
> > great design decision: they removed support of QTDIR env var :angry:
>
> The qtvars.bat file generated by the Qt Windows installer does almost
> exactly what you just described (it actually sets QTDIR, PATH, and
> QMAKESPEC). It works just fine for keeping multiple versions of Qt on
> a single Windows machine.
My qt distribution doesn't have such file(however I built it), but I
think that ever if I'll write similar qtvars.bat(what I've already
done for vars QTDIR, PATH, QMAKESPEC), my problem will not been
solved.
--
[ signature omitted ]
Message 30 in thread
On 27.08.07 16:19:24, BH wrote:
> > Well the OP claims that there are paths stored in the other executables
> > which makes them unusable. But thats plain wrong. Yes there is another
> > path always stored somewhere in the apps: The plugin installation path
> > for Qt. However you can always add new paths to search for plugins using
> > an environment variable, just as the API docs in
> > QCoreApplication::libraryPaths() say. So the only real issue with
> > "hardcoded paths in Qt executables" can be qmake when used for the
> > buildsystem.
>
> The hardcoded paths to QT are stored even inside the binaries of your
> programs you build.
> When I looked inside the .exe to figure yout why it is so large, I
> found that absolute paths to QT installation is stored in it (which is
> of course wrong, as the binary is shipped to other people - and they
> probably won't have QT at all, especially not in the same directory as
> me)
> So either the path is not used (then why it is there?) or is is used
> (and then it is wrong, as outside my machine it won't work)...
Did you read up on the stuff I mentioned? Yes the library path to Qt's
plugin install dir is hardcoded into the binaries. And that path is used
when trying to find plugins, of course that doesn't exist on consumer
machines. Thats why there's a number of fallbacks to find the plugins
(namely a plugins/ folder in the apps dir, a env var to add more paths
and an API to add paths)
Andreas
--
[ signature omitted ]
Pages: Prev | 1 | 2 | 3 | Next
