Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-interest Archive, July 2007
Re: Fwd: [cygwin] problems compiling qt4


Message 1 in thread

F X wrote:

> I have an native linux application (it is lmms.sourceforge.net; but it does
> not matter) which utilizes qt4 toolkit.

It matters quite a bit, really, since the non-Qt dependencies the app
has and the way it's written massively influence how easy it is to port
to other environments.

> So in order to make it run on w$ndows I thought the best way would be to
> try crosscompile it on cygwin (since it is not written to be compilable
> somewhere else as on linux and they dont have the intention to).

Is this a build system issue? Dependency on Linux-specific features and
libraries? Details in the code (like use of non-standard C functions
from glibc etc)? A lack of testing on other platforms?

The reason why it's not supported on other platforms is quite important.

> While configuring qt4 under cygwin I came to forementioned error.
> What would you recommend to be the best approach now ?
> Is it possilbe to use qt4 toolkit's native windows port from cygwin (linux,
> in fact) and run it this way ? If so, how ? I dont seem to see any other
> approach now..

In short, "it depends".

My admittedly non-expert impression is that Cygwin really isn't a very
nice environment. I'd avoid depending on it if you can get a native
Windows build working instead.

If the application depends directly on X11, you might indeed be stuck
with Cygwin unless you can provide cross platform abstractions for the
low-level X11 stuff or rewrite it using Qt. I'd seriously consider the
latter two options in preference to depending on Cygwin and X11, which
even with the rootless X server really aren't a fun way to work.

For most other things, Cygwin won't help you much. I wouldn't expect
good (if any) results from things like sound hardware under cygwin for
example. If the application depends directly on Linux/*nix specific
things like ALSA you're probably out of luck unless you can undertake
the (probably big) job of abstracting these parts and providing a win32
implementation. It might not be possible under cygwin at all, only under
native win32.

I'd start your efforts not by trying to compile Qt, but rather by
identifying the dependencies of the application and figuring out how you
can satisfy them under:

	\- Cygwin

	- Native win32/MinGW

	- Native win32/VC++
          (which provides access to parts of the win32 APIs
           not available from MinGW, like GDI+)

Pick which is best suited for the job based on what you've learned in
your research and reading of the code, *then* start trying to port it.

In this case, it looks like your app supports sound access using SDL
(according to the build documentation), and that's a cross-platform
library that will provides platform-independent interfaces for things
like sound hardware access - including IIRC on Windows. So that's one
problem solved. You need to do that kind of research for all its
dependencies (including unstated ones you discover by looking at header
includes in the code, ioctl() use, etc) and figure out the best way to
port it.

In short, "just recompile on cygwin" won't usually work for non-trivial
applications, especially anything that talks to the hardware.

--
 [ signature omitted ] 

Message 2 in thread

Hi Craig!
pls see below


On 7/1/07, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> F X wrote:
>
> > I have an native linux application (it is lmms.sourceforge.net; but it
> does
> > not matter) which utilizes qt4 toolkit.
>
> It matters quite a bit, really, since the non-Qt dependencies the app
> has and the way it's written massively influence how easy it is to port
> to other environments.


----------------------
yes I know, but
I was directing the issue here because it was specifically qt4
compiling/configuring problem


> So in order to make it run on w$ndows I thought the best way would be to
> try crosscompile it on cygwin (since it is not written to be compilable
> somewhere else as on linux and they dont have the intention to).

Is this a build system issue? Dependency on Linux-specific features and
libraries? Details in the code (like use of non-standard C functions
from glibc etc)? A lack of testing on other platforms?

The reason why it's not supported on other platforms is quite important.


----------------------
The error which I received when ./configure qt4 open source and which I
posted to my first email which you probably dont have was;

/cygdrive/d/install/qt/qt-all-opensource-src-4.3.0/src/corelib/global/qglobal.cpp:1665:
error: expected init-declarator before "winVersion"
/cygdrive/d/install/qt/qt-all-opensource-src-4.3.0/src/corelib/global/qglobal.cpp:1665:
error: expected `,' or `;' before "winVersion"
/cygdrive/d/install/qt/qt-all-opensource-src-4.3.0/src/corelib/global/qglobal.cpp:1761:
error: expected init-declarator before "QSysInfo"
/cygdrive/d/install/qt/qt-all-opensource-src-4.3.0/src/corelib/global/qglobal.cpp:1761:
error: expected `,' or `;' before "QSysInfo"
make: *** [qglobal.o] Error 1

[ I suppose the lack of testing on this platform was by qt4 people since the
this is a WIN23/CYGWIN #ifdef section :) ]



> While configuring qt4 under cygwin I came to forementioned error.
> What would you recommend to be the best approach now ?
> Is it possilbe to use qt4 toolkit's native windows port from cygwin
(linux,
> in fact) and run it this way ? If so, how ? I dont seem to see any other
> approach now..

In short, "it depends".

My admittedly non-expert impression is that Cygwin really isn't a very
nice environment. I'd avoid depending on it if you can get a native
Windows build working instead.

If the application depends directly on X11, you might indeed be stuck
with Cygwin unless you can provide cross platform abstractions for the
low-level X11 stuff or rewrite it using Qt. I'd seriously consider the
latter two options in preference to depending on Cygwin and X11, which
even with the rootless X server really aren't a fun way to work.

For most other things, Cygwin won't help you much. I wouldn't expect
good (if any) results from things like sound hardware under cygwin for
example. If the application depends directly on Linux/*nix specific
things like ALSA you're probably out of luck unless you can undertake
the (probably big) job of abstracting these parts and providing a win32
implementation. It might not be possible under cygwin at all, only under
native win32.

I'd start your efforts not by trying to compile Qt, but rather by
identifying the dependencies of the application and figuring out how you
can satisfy them under:

       \- Cygwin

       - Native win32/MinGW

       - Native win32/VC++
         (which provides access to parts of the win32 APIs
          not available from MinGW, like GDI+)

Pick which is best suited for the job based on what you've learned in
your research and reading of the code, *then* start trying to port it.

In this case, it looks like your app supports sound access using SDL
(according to the build documentation), and that's a cross-platform
library that will provides platform-independent interfaces for things
like sound hardware access - including IIRC on Windows. So that's one
problem solved. You need to do that kind of research for all its
dependencies (including unstated ones you discover by looking at header
includes in the code, ioctl() use, etc) and figure out the best way to
port it.

In short, "just recompile on cygwin" won't usually work for non-trivial
applications, especially anything that talks to the hardware.

----------------------

You are, basically right.
As for the application - I just wanted give it a try to do the compiling
with cygwin.
I succesfully compiled and run other linux audio apps (namely mpg123 for
example), so it would be nice if this one's runnable in cygwin too.
But for now I'd be probably just stuck with it because of lack of support
from qt4 to do so.
Probably it just requires carefully review the code, put some include/s
(somewhere), possibly modify #ifdef's section and such, but I didnt have
time for this..

thanks for the reply anyway

mc


--
 [ signature omitted ]