| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 6 | |
Is it possible to build a completely static app using Qt 4 on Linux? My problem is I'm trying to build an application that will run on a variety of recent (2.6.x kernel) distros. My first attempt (using shared libraries) results in "Floating point exceptions" when run on Debian. So now I'm looking at building statically. I was able to add a -static flag to my link flags in my .pro file, and I'm linking against static Qt libs, but when it gets to linking in libSM, it only finds the dynamic version and stops. I'm sure this is also the case for most of the X11 libraries. Can this be made to work? Or am I stuck building dynamically on a multitude of distros? This is a commercial application so providing source is not an option. -- [ signature omitted ]
On Thursday 28 February 2008 16:19:21 Paul Miller wrote: > Is it possible to build a completely static app using Qt 4 on Linux? Completely static? No. Almost completely static? Yes. The GNU Libc library's NSS subsystem still requires dynamic loading of some modules in order to fullfil your requests, especially when it comes to DNS resolution. If you don't use QTcpSocket or QHostInfo, you probably will get a fully static binary though. Make sure you have static libs for all Qt dependencies. They will be linked into your executable, which will be several megabytes in size. Better than that is to have Qt as a static library, but nothing else. That will link Qt into your program, but will dynamically load the libraries it needs from the system. I believe that's the approach that Skype uses on their static binaries. > My problem is I'm trying to build an application that will run on a > variety of recent (2.6.x kernel) distros. My first attempt (using shared > libraries) results in "Floating point exceptions" when run on Debian. So > now I'm looking at building statically. My suggestion is to try the linux-lsb-g++ mkspec if you intend to deploy a Qt application in several different Linux systems. But I don't see how floating point exceptions can have anything to do with the Qt build. Maybe if you post a code sample and/or a backtrace of the crash, we can help with that instead. Be sure that you build your application on the "lowest common denominator" platform of yours, since libc and libstdc++ are not forwards compatible (i.e., you have to link to the lowest version you intend to deploy on). This applies even if you replace the headers of those libraries with older headers. (There's a link-time dependency, whereas Qt is only compile-time) > I was able to add a -static flag to my link flags in my .pro file, and > I'm linking against static Qt libs, but when it gets to linking in > libSM, it only finds the dynamic version and stops. I'm sure this is > also the case for most of the X11 libraries. Like I said above, you need to have the static library for all dependencies if you want to have a fully static build. > Can this be made to work? Or am I stuck building dynamically on a > multitude of distros? There's always LSB. The recently-announced LSB 3.2 contains Qt 4.2 as part of the required standard. Any Linux distribution conforming to LSB 3.2 will have that. Most recent Linux distributions already ship Qt 4.2 or even 4.3 (thanks to the KDE 4 release). The previous LSB 3.1 standard contained Qt 4.1 but only as an optional module. It has been out for close to 2 years now, though, so you may have a wider variety of distribution targets. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Thursday 28 February 2008 10:27:33 am Thiago Macieira wrote: > On Thursday 28 February 2008 16:19:21 Paul Miller wrote: > > Is it possible to build a completely static app using Qt 4 on Linux? > > Completely static? No. > > Almost completely static? Yes. The GNU Libc library's NSS subsystem still > requires dynamic loading of some modules in order to fullfil your requests, > especially when it comes to DNS resolution. If you don't use QTcpSocket or > QHostInfo, you probably will get a fully static binary though. > > Make sure you have static libs for all Qt dependencies. They will be linked > into your executable, which will be several megabytes in size. > > Better than that is to have Qt as a static library, but nothing else. That > will link Qt into your program, but will dynamically load the libraries it > needs from the system. > > I believe that's the approach that Skype uses on their static binaries. > > > My problem is I'm trying to build an application that will run on a > > variety of recent (2.6.x kernel) distros. My first attempt (using shared > > libraries) results in "Floating point exceptions" when run on Debian. So > > now I'm looking at building statically. > > My suggestion is to try the linux-lsb-g++ mkspec if you intend to deploy a > Qt application in several different Linux systems. > > But I don't see how floating point exceptions can have anything to do with > the Qt build. Maybe if you post a code sample and/or a backtrace of the > crash, we can help with that instead. For a not-yet-ported-to-qt4 app, I've seen that configuring Qt3 without xinerama removes floating point exceptions when distributing on some platforms. I haven't checked to see if Qt4 has the same issue, or why it was xinerama & Qt. Modifying the Qt code, and linking with the static xinerama library also solved the problem. Clint -- [ signature omitted ]
On February 28, 2008 10:49:24 am clinton@xxxxxxxxxxxx wrote: > On Thursday 28 February 2008 10:27:33 am Thiago Macieira wrote: > > On Thursday 28 February 2008 16:19:21 Paul Miller wrote: > > > Is it possible to build a completely static app using Qt 4 on Linux? > > > > Completely static? No. > > > > Almost completely static? Yes. The GNU Libc library's NSS subsystem still > > requires dynamic loading of some modules in order to fullfil your > > requests, especially when it comes to DNS resolution. If you don't use > > QTcpSocket or QHostInfo, you probably will get a fully static binary > > though. > > > > Make sure you have static libs for all Qt dependencies. They will be > > linked into your executable, which will be several megabytes in size. > > > > Better than that is to have Qt as a static library, but nothing else. > > That will link Qt into your program, but will dynamically load the > > libraries it needs from the system. > > > > I believe that's the approach that Skype uses on their static binaries. > > > > > My problem is I'm trying to build an application that will run on a > > > variety of recent (2.6.x kernel) distros. My first attempt (using > > > shared libraries) results in "Floating point exceptions" when run on > > > Debian. So now I'm looking at building statically. > > > > My suggestion is to try the linux-lsb-g++ mkspec if you intend to deploy > > a Qt application in several different Linux systems. > > > > But I don't see how floating point exceptions can have anything to do > > with the Qt build. Maybe if you post a code sample and/or a backtrace of > > the crash, we can help with that instead. > > For a not-yet-ported-to-qt4 app, I've seen that configuring Qt3 without > xinerama removes floating point exceptions when distributing on some > platforms. > I haven't checked to see if Qt4 has the same issue, or why it was xinerama > & Qt. > > Modifying the Qt code, and linking with the static xinerama library also > solved the problem. For our static builds, I use the following Qt4 and Qt3 configuration options: Qt4 ./configure -release -static -no-accessibility -no-sql-db2 -no-s ql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite -no- sql-sqlite2 -no-sql-tds -no-mmx -no-3dnow -no-sse -no-sse2 -qt-zlib -qt-gif -qt- libtiff -qt-libpng -qt-libmng -qt-libjpeg -no-openssl -no-nis -no-iconv -no-qdbu s -no-nas-sound -no-opengl -no-sm -no-xshape -no-xinerama -no-xcursor -no-xfixes -no-xrandr -no-xrender -no-fontconfig -no-tablet -no-xkb Qt3 ./configure -release -static -qt-gif -qt-zlib -thread -qt-imgfmt -png -qt-imgfmt-jpeg -disable-iconview -disable-workspace -disable-canvas -disab le-table -disable-opengl -disable-sql -no-sm -no-xshape -no-xinerama -no-xcursor -no-xrandr -no-xrender -no-xft -no-tablet -no-xkb Actually, the Qt3 options end up breaking the build so rather than doing a full build, I do: make symlinks src-qmake src-moc sub-src cd src && make install I'd welcome feedback if anyone disagrees with any of these options. :) -- [ signature omitted ]
On Friday 29 February 2008 04:27:33 am Thiago Macieira wrote: > But I don't see how floating point exceptions can have anything to do with > the Qt build. Maybe if you post a code sample and/or a backtrace of the > crash, we can help with that instead. I've seen a lot of crashes (given how poor a programmer I am, its not that surprising :-)). SIGFPE is normally a "look for a possible divide by zero" error. If it happens on some platforms and not others, you could be seeing the difference between a library that protects against bad inputs and one that doesn't. Or possibly the code path changes across platforms (which means the denominator doesn't get initialised). Good luck. Brad -- [ signature omitted ]
Brad Hards wrote: > On Friday 29 February 2008 04:27:33 am Thiago Macieira wrote: >> But I don't see how floating point exceptions can have anything to do with >> the Qt build. Maybe if you post a code sample and/or a backtrace of the >> crash, we can help with that instead. > I've seen a lot of crashes (given how poor a programmer I am, its not that > surprising :-)). > > SIGFPE is normally a "look for a possible divide by zero" error. If it happens > on some platforms and not others, you could be seeing the difference between > a library that protects against bad inputs and one that doesn't. Or possibly > the code path changes across platforms (which means the denominator doesn't > get initialised). It's not a real floating point exception. I was getting the same error when trying to run a pure C "Hello, World" program that just prints to stdout. It's some kind of bizarre difference in the std c library or something. I even had someone tell me he was getting the exception when running "ldd" on my app! It turns out things seem to be working when I *build* on Debian and run on CentOS, rather than the other way around. I don't know what the main difference is - they both have 2.6.x kernels and brand new runtimes, but oh well. -- [ signature omitted ]
Thiago Macieira wrote: > On Thursday 28 February 2008 16:19:21 Paul Miller wrote: >> Is it possible to build a completely static app using Qt 4 on Linux? > > Completely static? No. > > Almost completely static? Yes. The GNU Libc library's NSS subsystem still > requires dynamic loading of some modules in order to fullfil your requests, > especially when it comes to DNS resolution. If you don't use QTcpSocket or > QHostInfo, you probably will get a fully static binary though. > > Make sure you have static libs for all Qt dependencies. They will be linked > into your executable, which will be several megabytes in size. > > Better than that is to have Qt as a static library, but nothing else. That > will link Qt into your program, but will dynamically load the libraries it > needs from the system. Okay, making progress. Everything I can make static is static, but I still have a LOT of dynamic dependencies. I'm building on CentOS. When trying to run my app on Debian Etch, it's complaining about GLIBC_2.4 being missing. Poking around on various forums indicates that GLIBC_2.4 will never be supported in Etch, and there doesn't seem to be a simple way to just install it so it's there. Rather frustrating. So, how do I build my app using to have it require a lower version of GLIBC? Is it possible from my CentOS distro or will I have to install an older distro and just build everything from scratch there? It's amazing how much simpler all this is on Windows. I can build my app on any of my Windows boxes and it'll run on pretty much anything. -- [ signature omitted ]
On February 28, 2008 03:06:13 pm Paul Miller wrote: > Okay, making progress. Everything I can make static is static, but I > still have a LOT of dynamic dependencies. > > I'm building on CentOS. When trying to run my app on Debian Etch, it's > complaining about GLIBC_2.4 being missing. Poking around on various > forums indicates that GLIBC_2.4 will never be supported in Etch, and > there doesn't seem to be a simple way to just install it so it's there. > Rather frustrating. > > So, how do I build my app using to have it require a lower version of > GLIBC? Is it possible from my CentOS distro or will I have to install an > older distro and just build everything from scratch there? The easiest approach is to install an earlier distribution and compile there. It's worth considering whether you couldn't just build on Debian Etch and then run the resulting static version on CentOS. That is, the other way around to what you are doing. I believe it is possible to build your own version of glibc 2.3 on CentOS and link against that. I'm not saying this would be trivial, though. > It's amazing how much simpler all this is on Windows. I can build my app > on any of my Windows boxes and it'll run on pretty much anything. On the other hand, Windows package management system is all but non-existent and good luck trying to install and configure, say, postgres and adding a database account so that your own software can immediately start using a database system. And let's not forget that Windows suffers from C library versioning issues as well. Having recently worked on porting our app to Windows and packaging our app in both Linux and Windows, I think it is unfair to say one platform is clearly better than another. My dream is that TrollTech releases a software packaging/install solution that just works on Windows and various distributions of Linux, as well as providing static builds. I suspect this was literally just a dream, though, and that they aren't working on anything like this. :( -- [ signature omitted ]
Quoting Chris Thompson <cthompson@xxxxxxxxxxxxxxx>: > My dream is that TrollTech releases a software packaging/install > solution that > just works on Windows and various distributions of Linux, as well as > providing static builds. I suspect this was literally just a dream, though, > and that they aren't working on anything like this. :( Have you taken a look at InstallJammer? http://www.installjammer.com/ -- [ signature omitted ]
On February 28, 2008 04:20:34 pm Pau Garcia i Quiles wrote: > Quoting Chris Thompson <cthompson@xxxxxxxxxxxxxxx>: > > My dream is that TrollTech releases a software packaging/install > > solution that > > just works on Windows and various distributions of Linux, as well as > > providing static builds. I suspect this was literally just a dream, > > though, and that they aren't working on anything like this. :( > > Have you taken a look at InstallJammer? http://www.installjammer.com/ Can InstallJammer create deb and rpm packages? And handle dependency issues? My understanding was that it couldn't create deb and rpm packages but I can't find a confirmation on their website. This is not necessarily a problem for most people, mind you. -- [ signature omitted ]
Quoting Chris Thompson <cthompson@xxxxxxxxxxxxxxx>: > On February 28, 2008 04:20:34 pm Pau Garcia i Quiles wrote: >> Quoting Chris Thompson <cthompson@xxxxxxxxxxxxxxx>: >> > My dream is that TrollTech releases a software packaging/install >> > solution that >> > just works on Windows and various distributions of Linux, as well as >> > providing static builds. I suspect this was literally just a dream, >> > though, and that they aren't working on anything like this. :( >> >> Have you taken a look at InstallJammer? http://www.installjammer.com/ > > Can InstallJammer create deb and rpm packages? And handle dependency issues? > My understanding was that it couldn't create deb and rpm packages but I can't > find a confirmation on their website. > > This is not necessarily a problem for most people, mind you. I don't know, I use CMake and CPack, which do create .deb, .rpm, in addition to Windows and Mac installers :-) -- [ signature omitted ]
Thiago Macieira wrote: > My suggestion is to try the linux-lsb-g++ mkspec if you intend to deploy a Qt > application in several different Linux systems. > Only one problem (that I came across) with that: last time I checked, Fedora appears to have no interest whatsoever in picking up the LSB. My solution for this issue - and an ugly one it is, too - was to build an entire cross-compiler chain targeted at glibc 2.2, and building all the library dependencies I required for my project with that compiler (static or otherwise). Now this was not a Qt-based project, so I don't know how well this approach would extend to Qt... but the first challenge you're going to face is glibc symbol versioning. You will have to link against the oldest glibc that you intend to support. In my case, that extended back far enough that I couldn't just build on a distro that old - the compiler shipped with that distro was too old to compile my code! I found that in my case, full static linking wasn't necessary; I just needed to have a "lowest common denominator" toolchain and libraries. -- [ signature omitted ]
On Thursday 28 February 2008 07:19:21 am Paul Miller wrote: > My problem is I'm trying to build an application that will run on a > variety of recent (2.6.x kernel) distros. My first attempt (using shared > libraries) results in "Floating point exceptions" when run on Debian. So > now I'm looking at building statically. You've already had some good responses, but I'll add a bit of detail in one area. Here's the approach I took. 1) Figure out which distro is the oldest system that we want to support and what it's provides for libraries. For example, does it provide: xfixes, xinerama, xshape, fontconfig, etc. 2) Grab the LSB package for whatever is selected in #1 above. 3) If necessary, compile a newer g++ using the lsb++ compiler. 4) Using g++ (if it was compiled in step #3) or lsb++, compile Qt using the appropriate options for the system in #1 (and generally don't rely on ANY optional system packages, eg. use qt's png, jpg, etc. libraries). 5) Compile your app against Qt built in #4 and using the same compiler as Qt was compiled with. 6) Package the necessary Qt and g++ libraries together with your app. 6) Include in that package a wrapper shell script that sets LD_LIBRARY_PATH as necessary so that the correct libraries are picked up when your binary is executed. This has worked great for us. As our oldest system doesn't support fontconfig and anti-aliasing, etc., we actually provide a second package that's a bit newer and requires a few more X libraries, but it sometimes works better (it's actually kind of odd, but in a few cases, the older version without fontconfig support, etc. actually looks much better on some of the new distros.) I hope that helps. Kaleb Pederson Soph-Ware Associates, Inc. http://www.soph-ware.com/ > I was able to add a -static flag to my link flags in my .pro file, and > I'm linking against static Qt libs, but when it gets to linking in > libSM, it only finds the dynamic version and stops. I'm sure this is > also the case for most of the X11 libraries. > > Can this be made to work? Or am I stuck building dynamically on a > multitude of distros? > > This is a commercial application so providing source is not an option. -- [ signature omitted ]
Paul Miller <paul@xxxxxxxxxx> wrote: > Is it possible to build a completely static app using Qt 4 on Linux? > > My problem is I'm trying to build an application that will run on a > variety of recent (2.6.x kernel) distros. My first attempt (using shared > libraries) results in "Floating point exceptions" when run on Debian. So > now I'm looking at building statically. > > I was able to add a -static flag to my link flags in my .pro file, and > I'm linking against static Qt libs, but when it gets to linking in > libSM, it only finds the dynamic version and stops. I'm sure this is > also the case for most of the X11 libraries. > > Can this be made to work? Or am I stuck building dynamically on a > multitude of distros? > > This is a commercial application so providing source is not an option. > I'm not sure if building Qt statically is allowed for non-GPL applications: as I know, if an application uses LGPL libraries, it is only allowed to build it statically if this application is GPL. So, if Qt is uses LGPL library it should not be allowed for non open source application to provide statically build applications. -- [ signature omitted ]
sebastien_fricker@xxxxxxxx wrote: > Paul Miller <paul@xxxxxxxxxx> wrote: >> Is it possible to build a completely static app using Qt 4 on Linux? >> >> My problem is I'm trying to build an application that will run on a >> variety of recent (2.6.x kernel) distros. My first attempt (using shared >> libraries) results in "Floating point exceptions" when run on Debian. So >> now I'm looking at building statically. >> >> I was able to add a -static flag to my link flags in my .pro file, and >> I'm linking against static Qt libs, but when it gets to linking in >> libSM, it only finds the dynamic version and stops. I'm sure this is >> also the case for most of the X11 libraries. >> >> Can this be made to work? Or am I stuck building dynamically on a >> multitude of distros? >> >> This is a commercial application so providing source is not an option. >> > I'm not sure if building Qt statically is allowed for non-GPL > applications: as I know, if an application uses LGPL libraries, it is > only allowed to build it statically if this application is GPL. > > So, if Qt is uses LGPL library it should not be allowed for non > open source application to provide statically build applications. What I ended up doing is linking statically with anything I could link statically with that was not LGPL - this includes Qt, which I have a commercial license for, Python, and OpenEXR. I'm also building on a "lowest-common-denominator" configuration. But I have two problems with this whole situation: 1. why do I need to build on a lowest-common denominator system anyway? So I (and Qt, and other libs) are using functions down in clib (and other libs), like memcpy, fopen, etc. It seems to me that it shouldn't matter what version of the clib is installed on the various distributions, as long as they expose those functions using their well-known signatures. When I first copied my app (built on CentOS 5.1) onto a Debian Etch system, *all* of the dependent libraries were present - there were no complaints from ldd, yet it wouldn't run. That doesn't make sense to me. If the actual functions are there, why should it matter which VERSION of glibc for example is actually there? This is a rhetorical question of course - I know there is no simple answer. But compare this to Windows development, where all I need to do is install (or have the user install) the .NET 2.0 runtime, which comes in a single, readily available package, and we're good to go. 2. As far as static linking against SYSTEM libraries go - if it actually worked, it wouldn't bother me in the least if I'm "not supposed to do it". My customers don't care if they can't replace some tiny part of it for "freedom" reasons. They just want to run my app to get their work done. This concept seems to be missed by a lot of people, for purely religious reasons. But, it's still better than Mac development, where Apple can (and does, often) just come along and push an update out that breaks everything. At least Linux (and for the most part, Windows) has a quite good semblance of forward compatibility. -- [ signature omitted ]