| Trolltech Home | Qt4-preview-feedback Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
MOTIVATION: =========== We (like others I suspect) are very interested in building Qt with the LSB 3.1 compiler, as this will allow us to distribute more recent Qt4 libraries with out products than those that are included as part of the LSB 3.1 Desktop module. This is our motivation for wanting to build Qt4.4 with the linux-lsb-g++ make specs rather than the default linux-g++ make specs. If this were possible, we could greatly reduce the number of packages we need to provide for clients to install on their machines (ie no need to create distribution-specific packages, just one for 32-bit LSB3.1 systems and one for 64-bit LSB3.1 systems). CAVEAT: ======= I realize that the linux-lsb-g++ make specs are not currently included in the list of platforms the tech preview has been tested with (as specified in the README file in the source package). I am hoping that this might change. ;) PROBLEMS ENCOUNTERED (so far!): =============================== (1) The Qt4.4 tech preview configure step seems to conclude that fontconfig is not supported when using the linux-lsb-g++ make specs. This is unexpected, since fontconfig is included as part of the LSB 3.1 specification. While this doesn't prevent Qt4.4 from being built, it will disable anti-aliasing on fonts which would be an undesirable omission. It is nice to see that the freetype detection/handling appears to have been fixed though since Qt4.3.0 (previous support emails about this back in June 2007). (2) Some parts of the source code call functions not included in the LSB3.1. For example, once a successful configure step has been performed, the build fails for me with the following: =========START=========== lsbc++ -c -pipe -DQT_LSB ...(stuffomitted)... io/qfilesystemwatcher_dnotify.cpp io/qfilesystemwatcher_dnotify.cpp: In member function âvirtual QStringList QDnotifyFileSystemWatcherEngine::addPaths(const QStringList&, QStringList*, QStringList*)â: io/qfilesystemwatcher_dnotify.cpp:256: error: â::dirfdâ has not been declared io/qfilesystemwatcher_dnotify.cpp:257: error: â::dirfdâ has not been declared io/qfilesystemwatcher_dnotify.cpp:260: error: âF_SETSIGâ was not declared in this scope io/qfilesystemwatcher_dnotify.cpp:261: error: âF_NOTIFYâ was not declared in this scope io/qfilesystemwatcher_dnotify.cpp:261: error: âDN_MODIFYâ was not declared in this scope io/qfilesystemwatcher_dnotify.cpp:261: error: âDN_CREATEâ was not declared in this scope io/qfilesystemwatcher_dnotify.cpp:261: error: âDN_DELETEâ was not declared in this scope io/qfilesystemwatcher_dnotify.cpp:262: error: âDN_RENAMEâ was not declared in this scope io/qfilesystemwatcher_dnotify.cpp:262: error: âDN_ATTRIBâ was not declared in this scope io/qfilesystemwatcher_dnotify.cpp:262: error: âDN_MULTISHOTâ was not declared in this scope =========END=========== The global dirfd() function is not in the LSB 3.1 spec, it is a BSD extension and not even POSIX according to its man page (although it says it is under consideration). A quick grep shows that qfilesystemwatcher_dnotify.cpp is the only place where this function is used. -- [ signature omitted ]
Hi, > MOTIVATION: > =========== > We (like others I suspect) are very interested in building Qt with the LSB > 3.1 compiler, as this will allow us to distribute more recent Qt4 libraries > with out products than those that are included as part of the LSB 3.1 > Desktop module. This is our motivation for wanting to build Qt4.4 with the > linux-lsb-g++ make specs rather than the default linux-g++ make specs. If > this were possible, we could greatly reduce the number of packages we need > to provide for clients to install on their machines (ie no need to create > distribution-specific packages, just one for 32-bit LSB3.1 systems and one > for 64-bit LSB3.1 systems). > I understand your motivation and we'll try to find a way to make this possible. However, since LSB is about to release LSB3.2 you should think about switching to that version, Qt 4.2 is a standard component of LSB3.2. We already started looking at what we could do regarding LSB 3.1, as soon as I have more information I'll let you know. Regards -- [ signature omitted ]
There will be a lot of customers stuck on LSB 3.1 machines for a long time to come (some are still on LSB 3.0 machines and will be for a couple of years yet - larger corporate customers especially tend to do this), so while it is great that Qt4.2 is potentially becoming part of LSB 3.2, it is not really a solution for those of us who want to use recent Qt versions in our software. There are some things in Qt4.4 that we are likely to want to incorporate, as would many other developers (lots of new goodies in 4.4!). Unfortunately, we would probably be waiting years before Qt4.4 was part of any LSB, then another few years before we could get away with expecting all our clients to be using Linux distributions that meet that LSB spec. Plenty of people are still using RHEL4 and SuSE9.3 for example, both of which are only LSB3.0 compliant. So to wait 3-5 years just to be able to use Qt4.4 in our software is not really a viable option. If, however, most Qt4.4 modules could be built with the LSB3.1 compliant compiler, this would allow the bulk of Qt4.4 functionality to be used immediately. Only the DBus module is likely to need to be left out, which we at least can tolerate. -----Original Message----- From: Carlos Manuel Duclos Vergara [mailto:carlos.duclos@xxxxxxxxxxxxx] Sent: Sat 12/22/2007 12:42 AM To: qt4-preview-feedback@xxxxxxxxxxxxx Cc: Scott, Craig (CMIS, Clayton) Subject: Re: Building Qt4.4 under LSB 3.1 (ie X11 only) Hi, > MOTIVATION: > =========== > We (like others I suspect) are very interested in building Qt with the LSB > 3.1 compiler, as this will allow us to distribute more recent Qt4 libraries > with out products than those that are included as part of the LSB 3.1 > Desktop module. This is our motivation for wanting to build Qt4.4 with the > linux-lsb-g++ make specs rather than the default linux-g++ make specs. If > this were possible, we could greatly reduce the number of packages we need > to provide for clients to install on their machines (ie no need to create > distribution-specific packages, just one for 32-bit LSB3.1 systems and one > for 64-bit LSB3.1 systems). > I understand your motivation and we'll try to find a way to make this possible. However, since LSB is about to release LSB3.2 you should think about switching to that version, Qt 4.2 is a standard component of LSB3.2. We already started looking at what we could do regarding LSB 3.1, as soon as I have more information I'll let you know. Regards -- [ signature omitted ]
Craig.Scott@xxxxxxxx wrote: >There will be a lot of customers stuck on LSB 3.1 machines for a long > time to come (some are still on LSB 3.0 machines and will be for a > couple of years yet - larger corporate customers especially tend to do > this), so while it is great that Qt4.2 is potentially becoming part of > LSB 3.2, it is not really a solution for those of us who want to use > recent Qt versions in our software. There are some things in Qt4.4 that > we are likely to want to incorporate, as would many other developers > (lots of new goodies in 4.4!). Unfortunately, we would probably be > waiting years before Qt4.4 was part of any LSB, then another few years > before we could get away with expecting all our clients to be using > Linux distributions that meet that LSB spec. Plenty of people are still > using RHEL4 and SuSE9.3 for example, both of which are only LSB3.0 > compliant. So to wait 3-5 years just to be able to use Qt4.4 in our > software is not really a viable option. If, however, most Qt4.4 modules > could be built with the LSB3.1 compliant compiler, this would allow the > bulk of Qt4.4 functionality to be used immediately. Only the DBus > module is likely to need to be left out, which we at least can > tolerate. You can build any Qt-based application against an LSB compiler and environment. The surprise comes when you see that you must bundle Qt and maybe some of the supporting libraries with your application (or statically link to them), in order to be able to run. In modern Linux distributions, probably shipping the Qt libraries is going to be enough (like last.fm does), but that's not LSB-compliant. Now, I am not sure when the required supporting libraries were introduced to LSB. But I am sure that Qt requires more from the system than LSB provides. This is the case in 3.1 and 3.2 -- in other words, there is some desktop functionality that is only provided through Qt. For example, LSB 3.1 did not support libcups, but Qt did support printing. (meaning that the only way to print was through Qt) Conclusion: Qt itself is not LSB compliant (never has been), which means you'd have to forego that functionality or ship the supporting library itself along with your application. What we need from you, dear users, is that you urge your distributors to upgrade their Qts in their platforms. LSB standardises on common, current practice. Last year, when we were working on LSB 3.1, we had a lot of discussion on whether Qt should be present at all or not, and then we ended up with an option module only. And the reason was that some distributors had not decided to include Qt4. So, if you're a paying costumer to those LSB-certified products, make sure you make your opinions known. Let them know that you want WebKit support or multimedia support or <insert favourite feature here>. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.