Qt-interest Archive, March 2007
libQtGui.so
Message 1 in thread
Hi i have developed a program under suse linux,
now i want to test it on other linux machines, but i was unable to run
it without, and it complained about that shared library.
What should i do?
--
[ signature omitted ]
Message 2 in thread
On Monday 05 March 2007 13:55, suleiman wrote:
> Hi i have developed a program under suse linux,
> now i want to test it on other linux machines, but i was unable to run
> it without, and it complained about that shared library.
>
> What should i do?
1) simply copy this library to target machine :)
2) use static linking with Qt (parameter -static when use configure for build
Qt library)
--
[ signature omitted ]
Message 3 in thread
> 1) simply copy this library to target machine :)
> 2) use static linking with Qt (parameter -static when use configure for build
> Qt library)
Better use method 2. Since more and more 64 bit machines are used,
simply copying a lib is somewhat risky.
Guido
--
[ signature omitted ]
Message 4 in thread
Can you please explain how i can do method 2?
On 05.03.2007 12:19, Guido Seifert wrote:
>> 1) simply copy this library to target machine :)
>> 2) use static linking with Qt (parameter -static when use configure for build
>> Qt library)
>
>
> Better use method 2. Since more and more 64 bit machines are used,
> simply copying a lib is somewhat risky.
>
> Guido
>
>
> --
> 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
On Monday 05 March 2007 14:29, suleiman wrote:
> Can you please explain how i can do method 2?
As i wrote before:
when You build Qt library You give some parameters to program <configure>.
With these parameters You could give parameter <-static> and You'll have
libraryes for static linking.
These libraryes wll be placed to target directory QT_DIR/lib (instead of
libraryes for dinamic linking) and takes extension .a.
You can use these libraryes for static linking with Your program when all
other libraryes will be linked dinamically.
--
[ signature omitted ]
Message 6 in thread
Hi,
>> 1) simply copy this library to target machine :)
>> 2) use static linking with Qt (parameter -static when use configure for build
>> Qt library)
>
>
> Better use method 2. Since more and more 64 bit machines are used,
> simply copying a lib is somewhat risky.
Why would it be risky?
--
[ signature omitted ]
Message 7 in thread
On Mon, Mar 05, 2007 at 07:11:20PM +0100, Dimitri wrote:
> Hi,
>
> >>1) simply copy this library to target machine :)
> >>2) use static linking with Qt (parameter -static when use configure for
> >>build Qt library)
> >
> >
> >Better use method 2. Since more and more 64 bit machines are used,
> >simply copying a lib is somewhat risky.
>
> Why would it be risky?
Not risky in a sense that it necessarily disrupts the system. If someone
knows how and what to do it might be ok. But if it is a 32 bit lib and
you have 64 bit machine, where do you drop your lib? Into /usr/lib to
the other 64 bit libs? Ugly and potentially dangerous. In the same dir the
app is placed with the help of LD_LIBRARY_PATH? Still ugly and not very user
friendly.
I think instead of dumping some lib somewhere, circumventing whatever
package manager the system uses, using a statically linked binary is
preferable in such a case.
But maybe this is only my personal taste.
Guido
--
[ signature omitted ]
Message 8 in thread
Hi,
> Not risky in a sense that it necessarily disrupts the system. If someone
> knows how and what to do it might be ok. But if it is a 32 bit lib and
> you have 64 bit machine, where do you drop your lib? Into /usr/lib to
> the other 64 bit libs? Ugly and potentially dangerous. In the same dir the
> app is placed with the help of LD_LIBRARY_PATH? Still ugly and not very user
> friendly.
Shared libraries associated to a single application should never be
added to /usr/lib anyways - otherwise this all ends up in the DLL Hell
well known to Windows users. Microsoft has since suggested putting DLLs
in the same directory as the application directory. On Linux there are
alternatives but the spirit remains the same. For example, if the
program is distributed as an RPM package, put shared libraries
associated to an application into /usr/lib/<myapplication> or something
like that, and hard-code the path to libraries - resulting RPMs are of
course not relocatable. That's what's most programs distributed on Linux
as binaries do. I don't see what's ugly with it.
--
[ signature omitted ]
Message 9 in thread
> For example, if the
> program is distributed as an RPM package, put shared libraries
> associated to an application into /usr/lib/<myapplication> or something
> like that, and hard-code the path to libraries - resulting RPMs are of
> course not relocatable. That's what's most programs distributed on Linux
> as binaries do. I don't see what's ugly with it.
Ugliness depends on the concrete situation. There are cases where
statically linked libs cannot work, but if they do I think static
linking is the better and easiest solution.
What is the advantage of hard-coded pathes to libs?
You have to use some sort of installer. Just dropping a binary somewhere
does not suffice. You can use RPM, but not all distris use this crap, so
you limit your user base.
Then you said yourself that such a solution is not relocatable. If the
developer really choses /usr/lib/<myapplication> as place for the lib,
you have to install the RPM package as root. RPMs from some unknown
developer? Quite a security risk. I probably would not do it until I
read the installation scripts in the RPM. I hope the program is worth
the effort.
Apart from that, what is the advantage? A private lib for a single
program does not really save some space or other resources. Ok, if there
is a bug in the lib, it is easier fixed. I guess this possibility is
the main reason for commercial packages to use this method. For a hobby
programmer there is not much of a difference, distributing a new
statically linked app, or a new installer with a new fixed lib, I think.
Finally look at the original post in this thread. The original poster seems
to be a newbie. At least when it comes to libs. Creating RPMs (debs,
ebuilds) isn't that easy. I doubt he is willing to learn the RPM (or
other packaging) stuff, just to test his app on another machine.
For me enough reasons to call the non static solutions 'ugly'. :-)
Guido
--
[ signature omitted ]
Message 10 in thread
Hi,
> For me enough reasons to call the non static solutions 'ugly'. :-)
I agree it may easier to distribute a static executable than packaging
an executable and its dependencies.
I was thinking of large programs distributed as binaries (Mozilla and
Matlab for example). They are very often installed with shared libraries
in the same directory and launched by scripts. This could indeed be
overkill here. But I wouldn't call that 'ugly'.
--
[ signature omitted ]
Message 11 in thread
Dimitri wrote:
> > Not risky in a sense that it necessarily disrupts the system. If someone
> > knows how and what to do it might be ok. But if it is a 32 bit lib and
> > you have 64 bit machine, where do you drop your lib? Into /usr/lib to
> > the other 64 bit libs? Ugly and potentially dangerous. In the same dir the
> > app is placed with the help of LD_LIBRARY_PATH? Still ugly and not very user
> > friendly.
>
> Shared libraries associated to a single application should never be
> added to /usr/lib anyways - otherwise this all ends up in the DLL Hell
> well known to Windows users.
I strongy disagree. The "library managment system" on *nix system
has worked reasonably well for a few decades without running into DLL
hell as long as the applications stuck to a few rules (such as the
libfoo.so.major.minor.patch namining scheme -- as opposed to the
"kernel32.dll" and "mfc42.dll" "scheme" used in Redmond)
> Microsoft has since suggested
> putting DLLs in the same directory as the application directory.
And Microsoft is known to be a reliable source of information on how
to avoid DLL hell. Surely not...
> On Linux there are alternatives but the spirit remains the same.
> For example, if the
> program is distributed as an RPM package, put shared libraries
> associated to an application into /usr/lib/<myapplication> or something
> like that,
This is just a private namespace for your application. It is not
the concept of putting libraries into the same directory as the
binary. So this is completely orthogonal to the question discussed above.
> and hard-code the path to libraries - resulting RPMs are of
> course not relocatable. That's what's most programs distributed on Linux
> as binaries do.
> I don't see what's ugly with it.
Hardcoding absolute paths? This is pretty ugly as it means that
any kind of custom installation will have to find its own way
of symlinking stuff to funny places just to make something work
that should work out-of-the-box...
Andre'
--
[ signature omitted ]
Message 12 in thread
Hi,
> I strongy disagree. The "library managment system" on *nix system
> has worked reasonably well for a few decades without running into DLL
> hell as long as the applications stuck to a few rules (such as the
> libfoo.so.major.minor.patch namining scheme -- as opposed to the
> "kernel32.dll" and "mfc42.dll" "scheme" used in Redmond)
The Qt build system has options. I'm 100% certain not everybody will use
the same options, whether there are "recommended standard" options or
not. Also some programs may rely on buggy behavior that has been fixed
in a later minor release. You just can't replace any library that's in
/usr/lib with you own copy of it when installing a program, just because
it seems more recent. Maybe the Qt libraries already in /usr/lib had
been patched by the Linux vendor, for one reason or another. Maybe it
won't result in problems as bad as on Windows, but that would still be a
small DLL hell.
Anyway, what I meant to say is that when deploying a Qt application on
Linux, I see the following solutions :
- static linking,
- dynamic linking, reusing the Qt libraries already installed on the
system (although I don't know what the legal status of linking at
run-time with a GPL'ed library a program that was compiled with the
commercial library),
- dynamic linking, distributing the Qt libraries together with the
executable and installing them in a private directory.
I wouldn't recommend installing the Qt libraries shipping with an
executable into /usr/lib.
> This is just a private namespace for your application. It is not
> the concept of putting libraries into the same directory as the
> binary. So this is completely orthogonal to the question discussed above.
Right, I was thinking about a private namespace. The directory of an
executable (if it's not /usr/bin of course) was just an example of a
private namespace.
>> I don't see what's ugly with it.
>
> Hardcoding absolute paths? [...]
No, I meant to say, what so ugly with private namespaces?
--
[ signature omitted ]
Message 13 in thread
without libQtGui.so as mentioned in the subject, dont know why it
became like that.
On 05.03.2007 11:58, shuchi, Agrawal (IE10) wrote:
>
>
> * without what??? *
>
>
>
> Thanks & Regards
>
> Shuchi Agrawal
>
> __________________Honeywell
>
> Honeywell Technology Solutions
>
>
>
> -----Original Message-----
> From: suleiman [mailto:suleimaj@xxxxxxxxxx]
> Sent: Monday, March 05, 2007 4:26 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: libQtGui.so
>
>
>
> Hi i have developed a program under suse linux,
>
> now i want to test it on other linux machines, but i was unable to run
>
> * it without???????????? *, and it complained about that shared library.
>
>
>
> What should i do?
>
>
>
> --
>
> 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 ]
